BA Thesis Sven Bliedung - Analyse Und Evaluation Von Anwendungsszenarien Dynamischer 3D Simulationen

Internationale Medieninformatik
HTW Berlin
Bachelor Thesis
Analyse und Evaluation von Anwendungsszenarien dynamischer 3D
Simulationen
Bachelor Thesis
Sven Bliedung
Internationaler Studiengang Medieninformatik
Fachbereich Wirtschaftswissenschaften II
Hochschule für Technik und Wirtschaft Berlin
1. Betreuer: Prof. Thomas Bremer

2. Betreuer: Prof. Carsten Busch
2
Inhaltsverzeichnis
1 EINLEITUNG .................................................................................................................................. 5
1.1 MOTIVATION .............................................................................................................................. 5

1.2 ZIEL............................................................................................................................................ 6
2 GRUNDLAGEN.............................................................................................................................. 7
2.1 ENTWICKLUNG ............................................................................................................................ 7

2.2 RIGID BODY DYNAMICS ............................................................................................................... 9
2.3 FLÜSSIGKEITEN ........................................................................................................................... 10
2.3.1 Allgemein ....................................................................................................................... 10
2.3.2 Emitter ............................................................................................................................ 10
2.3.2.1 Arten von Emittern ...................................................................................................................... 11
2.3.3 Constraints ..................................................................................................................... 14
2.3.3.1 Objekt Constraints ....................................................................................................................... 14
2.3.3.2 Cloth Constraints ......................................................................................................................... 15
2.3.4 Voxel-basierte Systeme ................................................................................................ 16
2.3.4.1 Container ...................................................................................................................................... 16
2.3.4.1.1 2D Voxel Grid........................................................................................................................... 16
2.3.4.1.2 3D Voxel Grid........................................................................................................................... 17
2.3.5 Partikel-basierte Systeme ............................................................................................. 19
2.3.5.1 Dynamische Felder ..................................................................................................................... 20
2.3.5.1.1 Einsatzgebiete ......................................................................................................................... 23
2.3.5.2 Intelligente und dumme Partikel ..............................................................................................24
2.3.5.3 Partikelmesh ................................................................................................................................. 25
2.4 CLOTH ..................................................................................................................................... 26
2.4.1 Berechnung ................................................................................................................... 27
2.4.1.1 Geometrische Verfahren ........................................................................................................... 27
2.4.1.2 Physikalische Verfahren.............................................................................................................. 29
2.4.1.2.1 Feynman Algorithmus ............................................................................................................ 29
2.4.1.2.2 Provot Algorithmus ................................................................................................................. 30
2.4.1.3 Partikelenergie-basierte Verfahren .......................................................................................... 32
3 SOLVER ....................................................................................................................................... 35
3.1 ECHTZEIT ENGINES ..................................................................................................................... 36

3.1.1 Ageia ............................................................................................................................. 36
3.1.2 Havok physics ................................................................................................................ 37
3.2 OFFLINE ENGINES ...................................................................................................................... 38
4 ENTSTEHUNG DES FILMS: WITH FLOW ........................................................................................ 39
4.1 DER ANFANG ........................................................................................................................... 40

4.2 PLANUNGSPHASE ...................................................................................................................... 42
4.2.1 Sicherheit ....................................................................................................................... 43
4.2.1.1 Ernährung ..................................................................................................................................... 43
4.2.1.2 Schlaf ............................................................................................................................................. 43
4.2.1.3 Sport ............................................................................................................................................... 43
4.3 ENTWICKLUNGSPHASE ................................................................................................................ 44
4.3.1 Produktions -Pipeline ..................................................................................................... 44
4.3.2 Projekt Pipeline .............................................................................................................. 45
4.3.3 Renderfarm.................................................................................................................... 48
3
4.3.3.1 Ist Zustand ..................................................................................................................................... 49

4.3.3.2 Soll Konzept .................................................................................................................................. 50
4.3.3.3 Analyse vorhandener Systeme ................................................................................................. 51
4.3.3.3.1 Mental Ray® Satellite ............................................................................................................. 51
4.3.3.3.2 Konfiguration ........................................................................................................................... 51
4.3.3.3.3 Tests ........................................................................................................................................... 52
4.3.3.3.4 Back Burner .............................................................................................................................. 52
4.3.3.3.5 Dr. Queue ................................................................................................................................. 52
4.3.3.3.6 Royal Render ........................................................................................................................... 53
4.3.3.4 Wahl der Renderlösung.............................................................................................................. 54
4.3.3.5 Installation ..................................................................................................................................... 55
4.3.3.6 Remotezugriff ............................................................................................................................... 56
4.3.3.7 Überprüfen der gerenderten Bilder ......................................................................................... 57
4.3.3.8 Netzwerkauslastung .................................................................................................................... 57
4.3.3.9 Lokale Texturen ............................................................................................................................ 58
4.3.3.10 Pfade ............................................................................................................................................. 58
4.3.3.11 Synchronisation ............................................................................................................................ 59
4.3.4 Render Pipeline ............................................................................................................. 61
4.4 SHOT PRODUKTION .................................................................................................................... 63
4.4.1 Einleitung ....................................................................................................................... 63
4.4.2 Modellierung und Texturierung .................................................................................... 64
4.4.2.1 Modellierung von Kleidung ....................................................................................................... 65
4.4.3 Shading .......................................................................................................................... 66
4.4.4 Licht ................................................................................................................................ 68
4.4.5 Rigging ........................................................................................................................... 69
4.4.6 Animation ...................................................................................................................... 70
4.4.7 Simulationen .................................................................................................................. 71
4.4.7.1 Szene 1 - Der Marktplatz ............................................................................................................ 71
4.4.7.2 Fahne Am Mast ........................................................................................................................... 72
4.4.7.3 Flyer am Stein ............................................................................................................................... 73
4.4.7.4 Welle auf der Promenade ......................................................................................................... 74
4.4.7.5 Stop Motion Simulation............................................................................................................... 75
4.4.7.6 Hintergrundcharaktere............................................................................................................... 76
4.4.7.7 Frau mit Kamera .......................................................................................................................... 77
4.4.7.8 Reißende Ringe ........................................................................................................................... 78
4.4.7.9 Blumen gießen ............................................................................................................................. 79
4.4.7.10 Wolken........................................................................................................................................... 81
4.4.8 Szene 2 – Seitengasse ................................................................................................... 82
4.4.9 Szene 3 – Hof Gelände ................................................................................................. 83
4.4.9.1 Kleiner Brunnen ............................................................................................................................ 83
4.4.9.2 Großer Brunnen............................................................................................................................ 84
4.4.9.3 Teeglas .......................................................................................................................................... 85
4.4.10 Szene 4 – Die Dose .................................................................................................... 86
4.4.10.1 Die Korridorwelle.......................................................................................................................... 88
4.5 KOMPOSITION ........................................................................................................................... 91
4.5.1 Renderpässe und Renderlayer .................................................................................... 91
4.5.2 Tiefenschärfe ................................................................................................................. 91
4.5.3 Bewegungsunschärfe ................................................................................................... 92
4.5.3.1 Integration der Productionsshader in Maya .......................................................................... 94
4.5.4 Kombination der einzelnen Kanäle ............................................................................. 96
4.6 STEINE AUF DEM WEG DER PRODUKTION ...................................................................................... 98
4.6.1 Servercrash .................................................................................................................... 98
4.6.2 Rendercrashes .............................................................................................................. 98
4.6.3 Fehler während des Rendervorgangs......................................................................... 99
4
4.6.3.1 Kaustische Photonenberechnungen ....................................................................................... 99

4.6.3.2 Cachedaten ................................................................................................................................ 99
4.6.3.3 Fehlerhafte Blöcke ....................................................................................................................100
4.6.3.4 Shadingfehler .............................................................................................................................100
4.6.4 Light Linking und Parti Volume ................................................................................... 101
4.6.4.1 IPR MAYA ....................................................................................................................................101
4.6.4.2 Royal Render Bugs ....................................................................................................................102
4.6.5 Freitag der 13. ............................................................................................................. 102
5 FAZIT ......................................................................................................................................... 104
6 EIGENSTÄNDIGKEITSERKLÄRUNG ............................................................................................ 105

5
1 Einleitung
Bekanntlich wissen wir alle, dass der Bereich der 3D-Simulation in den vergangenen
Jahren enormen Fortschritten im Gebiet der Berechnung von physikalisch
bezogenen Systemen, wie intelligenter Partikelsysteme und Stoffsimulation unterlag.
Durch neue Erkenntnisse konnten effizientere Algorithmen entwickelt werden, welche
Dank stetig steigender Leistungen im PC-Bereich erstmalig die Möglichkeit bieten,
komplexere Berechnungen auf standardisierten Heimsystemen durchführen zu
lassen.
Da mein Wissen den Umfang dieser Arbeit sprengen würde, konzentriere ich mich bei
den folgenden Ausführungen auf die wesentlichsten Punkte.
Im ersten Abschnitt werden die Grundlagen der 3D-Simulationen dargestellt. Der

zweite Bereich dient dem konkreten Anwendungsfall.
1.1 Motivation
Durch die Tätigkeit für eine Postproduktionsfirma habe ich die Erfahrung gemacht,
dass häufiger auf 3D- Simulationen zurückgegriffen wird, als diese direkt am Set zu
filmen. Besonders der Sektor der Flüssigkeitssimulation hat inzwischen vermehrt
Verwendung in Filmen und Computerspielen gefunden.
Dadurch, dass sich viele Szenarien viel kontrollierter in Computerumgebungen

generieren lassen, entstand somit ein völlig neuer Handlungsraum innerhalb der Film-
und Spielbranche.
Die Gesamtnachfrage ist durch diese Erkenntnis gewachsen und heute gibt es kaum
noch größere Produktionen, welche nicht ohne die Hilfe von 3D- Systemen arbeiten.
Diese Branche hat eine rasante Entwicklung genommen. Da für mich diese Thematik
eine Herausforderung darstellt, habe ich mich in meiner Freizeit intensiv auf dem
Gebiet der 3D- Animationen weitergebildet.
Mit der Erstellung dieser Arbeit gebe ich einen groben Überblick über die
Möglichkeiten dieser Technologie.
Einleitung 6
1.2 Ziel
Das Ziel der Arbeit ist es, verschiedene Problematiken dieser Systeme aufzugreifen
und deren Lösungsansätze zu realisieren und anschließend zu analysieren.
In dieser Arbeit soll es dabei speziell um die Berechnung von Flüssigkeiten sowie der
dynamischen Simulation von Softbodys1 und Kleidungsstücken gehen.
Dabei werden vorhandene Lösungen analysiert und die daraus gewonnen

Kenntnisse eingesetzt, um mehrere Testszenarien zu entwickeln. Anschließend werden
sämtliche Lösungen anhand eines 3D-animierten Kurzfilmes zur Erhöhung der
Anschaulichkeit dargestellt.
Während der Umsetzung soll ein guter Weg beschrieben werden, der als Anleitung
für zukünftige Projekte dienen kann.
1 Softbody, eng: weicher Körper oder deformierbare Objekte

Grundlagen 7
2 Grundlagen
2.1 Entwicklung
Fluid-Simulationen zählen erst seit kürzester Zeit zu den Berechnungssystemen, welche

langsam im Echtzeitbereich und Consumer-PCs Fuß fassen. Obwohl es anfangs
einige Unklarheiten über deren Erfolg im Spielebereich gab und die damalige PhysX-
Engine nur mittels zusätzlicher Hardware lief, welche sich schwer absetzten, kam der
Erfolg dann doch, als NVIDIA die Firma Ageia übernahm und deren Engine auf ihre
GPU 2 auslegte.
Da CPUs für einen möglichst großen Befehlssatz konzipiert sind und somit
allgemeineren Berechnungen dienen, während GPUs spezieller auf Vektor und
Pixelberechnungen abgestimmt sind, benötigen CPUs einen wesentlich größeren
Cache und eine größere Control Unit, was sich negativ auf die Größe der ALU3,
auswirkt.
GPUs haben somit die CPUs vor einiger Zeit von der Berechnungsgeschwindigkeit
überholt, was inzwischen von größeren Firmen erkannt wurde und mittlerweile
genutzt wird4(Abbildung 1: Vergleich GPU vs. CPU ).
2 GPU (Graphic Processing Unit) Vektorprozessor der Grafikeinheit

3 ALU (Arithmetic Logic Unit) die berechnende Einheit innerhalb der CPU
4 Programme werden nach und nach aus Echtzeitgründen auf die GPU umgestellt.
Grundlagen 8
3000
2500 HD3870
2000
GFLOPS
1500
HD2900
1000
1950 XTX
500
X850 X1800
2x QX9770
Pentium D Core 2 Duo
0 P4
2004 2005 2006 2006 Q3 2007 2007 Q3 2008
GPU 7 43 160 250 475 1056 2400

CPU 4,1 6,1 8,1 14,2 48 60
Zeitraum
Abbildung 1: Vergleich GPU vs. CPU 5
Während der QX97756 im Dualbetrieb die 60 Gigaflops-Grenze erreicht, liegen

aktuelle GPUs wie die der R700 von Radeon bei 2400 Gigaflops, was einem Faktor
von 40 entspricht.
NVIDIA entwickelte eine auf C basierende Spracherweiterung namens CUDA,

welche ausschließlich für Berechnungen auf der GPU entwickelt und 2007
veröffentlicht wurde. Inzwischen haben andere Hersteller die Möglichkeiten der GPUs
erkannt, und ihre Berechnungen auf diese verlagert. Auch der größte CPU-Hersteller
Intel plant in Zukunft mit einer eigenen GPU7 den Markt zu erobern.
Erst durch diese Entwicklung wurde es möglich, komplexere Berechnungen wie Cloth
oder Fluid in Echtzeit durchzuführen.
5 Daten direkt von den jeweiligen Herstellerseiten

6 Intel Prozessor mit 4 Kernen und 3,2Ghz
7 Codename Larrabee
Grundlagen 9
2.2 Rigid Body Dynamics
Bei Rigid Body Dynamics spricht man von der Physik starrer oder nicht deformierbarer
Körper. Sie zählt zu dem ersten physikalischen Berechnungsmodel, welches
Anwendung im Bereich der Computersimulation gefunden hat. (Featherstone, 2008)
Dabei werden hauptsächlich zwei physikalische Betrachtungsweisen verwendet:
Die Newtonsche Mechanik, welche die Bewegung von Körpern innerhalb

eines Raum-Zeit-Kontinuums abbildet.
Die Lagrangesche Mechanik8, welche zur Vereinfachung physikalischer

Probleme und der daraus resultierenden geringeren Rechenzyklen
Verwendung findet.
Dabei kommt es in der Computersimulation meistens nicht auf die exakte

Berechnung der physikalischen Umstände an, sondern auf den Versuch einen
Kompromiss zwischen Rechenzeit und Rechengenauigkeit zu finden, da es vor allem
um einen rein optisch realistisch wirkenden Prozess mit hoher
Berechnungsgeschwindigkeit geht (Herta, 2004).
Die Phasen der Berechnung werden in „Collision Detection“ und „Collision Response“
unterteilt, welche sich mit dem Problem der wechselseitigen Durchdringung
(Interpenetration) von Objekten (collision detection) und der daraus resultierenden
Neuberechnung (collision response) befassen.
Da die Berechnungszeit der Simulation mit ansteigender Anzahl von

Objektinteraktionen und Objektkomplexität zunimmt, wird die Komplexität der
einzelnen Körper in drei grundlegende Typen unterschieden, welche den
Berechnungsaufwand unterschiedlich stark beeinflussen. Da sich Primitives 9 sehr gut
für physikalische Berechnungen eignen, stellen diese die erste Typenklasse und somit
die schnellste berechenbare Klasse von Objekten dar. Konvexe Polyeder, welche ein
grobes Collisionsmesh10 um das Objekt bilden, bieten im Gegensatz zu einem
komplexen Mesh, weniger Punkte und somit weniger Berechnungsaufwand als das
komplizierte Ursprungsobjekt. Der dritte Typ behandelt das komplette Objekt mit allen
Punkten als Kollisionsobjekt (Polygon Soups) und bildet somit den größten
Berechnungsaufwand. Da durch steigende Objektkomplexität ein
Berechnungsanstieg zu verzeichnen ist, wird die Verwendung sehr komplexer Meshes
für physikalische Berechnungen im Echtzeitbereich, aber auch im Bereich der
Posteffekte, kaum eingesetzt. Vielmehr werden hier sinnvolle Stellvertreterobjekte
(Proxys) gewählt, welche in etwa über die gleiche Form verfügen, aber eine deutlich
kleinere Anzahl an Polygonen besitzen. (Ericson, 2005)
8 Benannt nach Joseph Louis Lagrange

9 Mathematische Grundkörper wie Kugeln, Quader, Zylinder etc.
10 Objekt, welches zur Berechnung von Kollisionen dient.
Grundlagen 10
2.3 Flüssigkeiten
2.3.1 Allgemein
Es gibt zwei mathematische Modelle, nach denen Fluid-Solver arbeiten, entweder

auf Basis von Voxeln oder jene, die auf Partikeln basieren. Generell gesehen kann
man mit beiden Verfahren die gleichen Effekte erzielen, wobei sich dennoch die
einzelnen Modelle für spezielle Anwendungsbereiche eignen. Voxel-basierte Systeme
zeugen selbst bei höheren Auflösungen von einem weicheren Look, sodass diese vor
allem für die Erzeugung von realistischen Feinstoffen wie Rauch, Staub oder Plasmen
ausgelegt sind. Partikel-basierte Systeme finden vermehrt Einsätze in der
Flüssigkeitssimulation von Stoffen mit fester Oberfläche11. Dabei können diese
innerhalb der Szenerie fest definiert oder mittels Emitter erzeugt werden(Kohlmann,
2007).
2.3.2 Emitter
Emitter generieren Partikel oder Voxel und können diverse Attribute an diese
während der Erzeugung übertragen. Dabei können Emitter auf unterschiedliche
Weise aufgebaut werden und unterschiedliche Funktionen erfüllen. Meistens
kommen sie dort zum Einsatz, wo mehrere Partikel/Voxel erzeugt werden sollen. Dies
kann direkt an einer festen Erzeugerquelle geschehen12. Sie können aber auch dazu
verwendet werden, weitere Objekte aus anderen Partikeln/Voxel zu generieren13
(Schönherr, 2006).
11 z. B. Wasser, Honig, Lava

12 z. B. bei einer Kerzenflamme oder einem Auspuff
13 Beispiel: Schaum, der von Partikeln generiert wird, welche mit anderen Objekten kollidieren.
Grundlagen 11
2.3.2.1 Arten von Emittern
Omni Emitter: Es wird in alle Richtungen emittiert (Abbildung 2).
Abbildung 2: Omni Emitter
Directional Emitter: Es wird in bestimmte Richtungen emittiert (Abbildung 3 ).14
Abbildung 3: direktionaler Emitter
14 Richtungen der x-, y- und z-Achse

Grundlagen 12
Surface Emitter: Ausstoß erfolgt aus einem Objekt (Abbildung 4).
Abbildung 4: Surface Emitter
Curve Emitter: Es wird auf Basis einer Kurve emittiert (Abbildung 5).
Abbildung 5: Curve Emitter

Grundlagen 13
Volume Emitter: Der Ausstoß erfolgt aus dem Volumen eines Objektes
(Abbildung 6).
Abbildung 6: volumetrischer Halbkreis Emitter

Grundlagen 14
2.3.3 Constraints
Ein Constraint stellt eine Einschränkung dar, dem die gekoppelten Objekte oder
einzelnen Objektteile unterliegen. Dabei gibt es mehrere Arten von Constraints,
welche unterschiedliche Verwendungen finden.(Schönherr, 2006)
2.3.3.1 Objekt Constraints
Objekt Constraints werden zwischen unterschiedlichen Objekten oder

Objektgruppen bestimmt. Dabei können Eigenschaften wie Position, Skalierung oder
Rotation zwischen Objekten oder einzelnen Nodes ausgetauscht werden. Man kann
sich Constraints als eine Art Vererbungskette vorstellen, in der Eigenschaften von
einem Objekt an ein weiteres vererbt werden.
Übliche Verwendungen finden unter anderem:
Point Constraints: Bedeutet die Limitierung des Bereiches der Translation

des Objektes z. B. wenn ein Objekt einem anderen von der Position
folgen soll.
Orient Constraints: Bedeutet die Limitierung der Rotation eines Objektes

z. B. Ventilator, bei dem die einzelnen Ventilatorblätter dem rotierenden
Kern folgen sollen.
Parent Constraints: Bedeutet die Limitierung auf die Translation und

Rotation eines Objektes
z. B. wenn eine Person etwas aufheben soll, können Translation und
Rotation der Hand auf das Objekt übertragen werden.
Scale Constraints: Sorgt für eine Skalierungslimitation des Objektes

z. B. wenn ein Objekt zusammen mit einem anderen schrumpfen oder
wachsen soll.
Aim Constraints: Rotationsattribute werden dahin gehend limitiert, dass

das Aim Constraint Objekt versucht, einem weiteren Objekt zu folgen
z. B. Augen, die jemandem hinterher schauen.
Grundlagen 15
2.3.3.2 Cloth Constraints
Sie stellen Einschränkungen dar, welche Einfluss auf die Simulation von Softbodys wie
Kleidungen nehmen. Die Bezeichnungen können dabei von den einzelnen
Softwarelösungen unterschiedlich sein, aber deren Anwendungen und Funktionen
sind insgesamt sehr ähnlich. Während dieser Arbeit wird die Bezeichnung der Maya
NConstraints verwendet.
Cloth Constraints:
Transform: Transform oder Pin Constraint genannt, pinnt die gewählten Punkte
des Meshes an einen Locator. Die Translationsdaten von diesem werden auf
die verbundenen Punkte übertragen, wodurch sich diese bewegen lassen.
Typisches Beispiel ist eine Wäscheleine, die an 2 Punkten gehalten werden soll.
Component to Component: bindet einzelne Objektelemente an ein weiteres

Objekt. Dadurch lassen sich Objekte an Kleidungsstoffe haften.
Point to Surface: bindet die einzelnen Cloth Elemente an Punkte eines

weiteren Meshes. Dies wird oft verwendet, wenn Kleidungsstücke nahe an der
Haut liegen.
Force Field: stellt im Grunde ein Radial Field (siehe Dynamische Felder) dar,
welches die einzelnen Kleidungselemente nach außen drücken soll. Das dient
dazu, um einzelne Interpenetrationen wieder zu korrigieren.
Tearable Surface: dient dem Zerreißen von Stoffen. Hier werden einzelne
Punkte des Kleidungsstoffes definiert, an welchen der Stoff in der Lage ist, zu
zerreißen. Je nach Glue Strenght15 geschieht dies bei leichten oder stärkeren
Krafteinwirkungen auf die einzelnen Punkte.
15Glue Strenght, engl. Klebkraft, definiert in Cloth Simulationen die Stärke des Zusammenhalts
von Punkten.
Grundlagen 16
2.3.4 Voxel-basierte Systeme
In der Berechnung volumetrischer Körper stellen Voxel 16 eine nicht wegzudenkende

Grundgröße dar. Sie beinhalten Pixelinformation, die mit zusätzlichen Tiefendaten
ausgestattet und an ein dreidimensionales Koordinatensystem gekoppelt sind. Sie
haben vor allem ihre Bedeutung im Volumen-Rendering, welches viel Verwendung
innerhalb medizinischer Simulationen, aber auch im Spielebereich hat.
2.3.4.1 Container
Voxel-basierte Systeme werden innerhalb eines sogenannten Containers simuliert.

Dieser wird oftmals als Fluid Container bezeichnet. Dabei handelt es sich um ein
räumlich begrenztes Gebiet, welches in einzelne kleinere Blöcke unterteilt wird, die
somit den Detailgrad der Simulation und des gesamten Berechnungsaufwandes
beeinflussen.
Obwohl ein Voxel zwar dadurch definiert ist, dass es ein volumetrisches Pixel darstellt,
unterscheidet man in der Praxis trotzdem zwischen 2D- und 3D Containern (Eric Keller,
2009).
2.3.4.1.1 2D Voxel Grid

Hierbei darf man nicht von der Fehlannahme ausgehen, dass ein 2D- Container
zweidimensionale Voxel enthalten könnte. Vielmehr besteht ein 2D- Container genau
aus nur einer Reihe von Voxeln, welche eine Tiefe besitzen. Die Auflösung, der Z-
Achse des Containers ist somit immer eins, während die Auflösung der X- und Y-
Achse frei definiert werden kann.
Beispiel eines 2D- Fluid- Containers siehe Abbildung 7
Abbildung 7: Beispiel 2D Fluid Container mit Strömungssimulation
16 Voxel bedeutet volumetrischer Pixel und ist ein Element eines volumetrischen Körpers.
Grundlagen 17
2.3.4.1.2 3D Voxel Grid

Der 3D- Container unterscheidet sich in dem Punkt, dass er im Vergleich zum 2D-
Container, zusätzlich noch über eine Auflösungstiefe in der Z Achse verfügt. Die
untere Abbildung stellt einen typischen Fluid Container dar. Die gelbe
Außenmarkierung zeigt den äußeren Bereich des Containers an, wobei die
Gitterblöcke die Auflösung definieren. Der Würfel vorne links im Container zeigt die
genaue Größe einer Auflösungstiefe.
Abbildung 8: 3D Fluid Container 8x19x8

Grundlagen 18
Das folgende Beispiel (Abbildung 9) zeigt eine Flammensimulation, die durch Voxel
aus einem primitiven sphärischen Körper generiert wird. Wie im Bild links zu erkennen
ist, wurde die Auflösung des Containers stark erhöht, um einen erhöhten Detailgrad
zu erreichen. Dabei simulieren die blauen Voxel das Fuel17 , die orangen Voxel die
Flamme und die Weißen den Rauch. Rechts kann man das daraus gerenderte Bild
erkennen.
Abbildung 9: 3D Fluidsimulation einer Flamme ( Auflösung: 50x60x99 )
17 Fuel, engl. Brennstoff

Grundlagen 19
2.3.5 Partikel-basierte Systeme
Partikel repräsentieren in der Computersimulation Punkte im Raum, welche

zusätzliche und erweiterbare Attribute wie z. B. Position, (gerichtete)
Geschwindigkeit, Farbe oder Form enthalten können. Partikel können in größeren
Gruppen zusammengefasst und koordiniert werden, welche man dann als
Partikelsystem bezeichnet. Dieses Partikelsystem beinhaltet globale Attribute, welche
an die darin befindlichen Partikel vererbt werden. Die Skalierbarkeit der Systeme und
dessen Attribute bieten eine breite Palette an Möglichkeiten für Simulationen,
welche vom Schwarmverhalten ganzer Tierherden bis hin zur Simulation einzelner
Wassertropfen reicht. Dabei werden die Partikelsysteme in „dumme“ und
„intelligente“ Systeme unterschieden. Dumme Partikel verfügen zwar über eine
Masse, Position, Beschleunigung und reagieren auf Kräfte, aber sie haben keine
wirkliche Raumbeziehung untereinander. Sie reagieren somit wie primitive rigide
Bodys und sind somit sehr schnell zu berechnen. (Pixar Animation Studios, 2001)
Dabei werden diese Punkte oftmals nur als Proxy18 verwendet, welche nach der
eigentlichen Physikberechnung sowohl durch Objekte, als auch durch Sprites19,
ersetzt werden. Eine weitere Möglichkeit besteht darin, aus einzelnen Partikeln ein
neues Gesamtobjekt zu generieren, wie es bei Flüssigkeitssimulation meistens der Fall
ist. Da die einzelnen Partikel kein Volumen haben, werden diese eher selten für
volumetrische Effekte20 eingesetzt als für festere Körper.
Daher finden sie mehr Verwendung bei der Fluid-Simulation für die Erzeugung von
unterschiedlichen Flüssigkeiten wie Wasser, Honig oder Ketchup.
18 Proxy, engl. „Stellvertreter“

19 zwei dimensionale Grafikelemente, welche oftmals mit animierten Texturen gekoppelt
werden.
20 Als volumetrische Effekte werden hier Effekte wie Wolken, Plasma oder Rauch bezeichnet.
Grundlagen 20
2.3.5.1 Dynamische Felder
Kraftfelder auch Fields (engl. Feld) genannt, dienen der Erzeugung von natürlichen
Kräften, welche Einflüsse auf die einzelnen Objekte nehmen. Dabei gelten diese
Felder für alle Objekte innerhalb eines Solvers. Durch sie können unterschiedliche
äußere Krafteinwirkungen wie Wind, Gravitation oder sonstige Felder simuliert
werden.(Michael Bender, 2006)
Dabei unterscheidet man folgende Feldtypen:
Drag Fields: Drag Fields bremsen die Partikel ab (vergleiche Abbildung 3 mit
Abbildung 10). Dabei kann die Stärke gerichtet angegeben
werden.
Abbildung 10: Drag Field

Grundlagen 21
Radial Field: Radial Fields können die Objekte entweder zu sich ziehen oder
auseinander drücken. Dabei ist die Position des Feldes
entscheidend.
Abbildung 11: Radial Field
Gravity Field: Ein Gravity Field dient zum Erzeugen von direktionalen Kräften
wie Gravitationen. Innerhalb einiger Anwendungen21 existiert
zusätzlich ein Newton Field. Dabei erfüllen beide exakt die
gleiche Funktion, denn auch das Gravity Field kann wie Newton
Field einen beliebigen Richtungsvektor besitzen.
Abbildung 12: Gravity Field
21 z. B. in Maya
Grundlagen 22
Vortex Field: Ein Vortex Field erzeugt einen Mittelpunkt, um den die Objekte
kreisen. Es findet unter anderem Verwendung beim Erzeugen
von Partikelströmungen wie Tornados.
Abbildung 13: Vortex Field
Turbulence Field: Das Turbulence Field erzeugt turbulentes Verhalten der einzelnen
Objekte. Innerhalb von Maya ist dies ein statisches Feld,
welchem die Partikel folgen. Für Änderungen des Feldes über
einen bestimmten Zeitraum wird oftmals über dessen
Phasenattribut animiert.
Abbildung 14: Turbulence Field

Grundlagen 23
2.3.5.1.1 Einsatzgebiete
In Simulationen kommen Felder meistens in Kombinationen zum Einsatz. Felder,

welche nur in einem bestimmten Bereich der Szenerie wirken sollen, lassen sich durch
primitive Objekte begrenzen. Auf diese Weise wird eine hohe Kontrolle über die
einzelnen Felder gewährleistet.
Felder können außerdem an Objekte gebunden werden. Dies kann sehr nützlich sein,
wenn Partikel nicht miteinander kollidieren oder ein gewisses Schwarmverhalten
besitzen sollen.
Grundlagen 24
2.3.5.2 Intelligente und dumme Partikel
Intelligente Partikel dagegen haben erweiterte Eigenschaften und folgen durch

gegenseitige Beeinflussung im Raum diversen Mustern. Für die Simulation von
Flüssigkeiten zählen z. B. erweiterte Attribute wie äußerer Luftdruck,
Oberflächenspannung oder Dichte (vergleiche Abbildung 15: dummes
Partikelsystem mit Abbildung 16: intelligentes Partikelsystem).
Beide scheinen auf den ersten Blick sehr ähnlich, unterscheiden sich jedoch
innerhalb der Animation. Beide Partikelsysteme verfügen über die gleiche
Gravitation und Emissionsrate22. Die Emitter und Partikelgröße sind in unserem Beispiel
exakt die gleichen.
Während die Partikel im dummen Partikelsystem einfach miteinander kollidieren,

folgen die Partikel in der Abbildung 16 dem Verhalten von Wasser. Dazu üben sie
Kräfte untereinander aus, wodurch es zu der typischen Tropfenbildung kommt.
Abbildung 15: dummes Partikelsystem
Abbildung 16: intelligentes Partikelsystem
22 Anzahl der Partikel, die pro Zeiteinheit vom Emitter generiert werden.
Grundlagen 25
2.3.5.3 Partikelmesh
Für die Berechnung realistischer Lichteffekte wie Refraktionen, Reflexionen oder

kaustische Photonenbrechungen, müssen die Partikel in ein Mesh23 überführt werden.
Für die Überführung gibt es verschiedene Möglichkeiten und Filter.
Nachdem die einzelnen Partikelpositionen berechnet wurden, kann nun ein Mesh
generiert werden, welches die vorhandenen Partikel umhüllt.
Abbildung 17: generiertes Mesh
Dieses Mesh dient nur zur besseren Darstellung der Simulation. Im Echtzeitbereich wird
das Mesh direkt während der Partikelsimulation generiert, während es in der
Produktionsumgebung von Filmen meistens erst nach der eigentlichen
Partikelsimulation erstellt wird. Anschließend wird nur das gecachte Mesh24, welches
unabhängig von der eigentlichen Partikelsimulation arbeitet, verwendet.
Man kann es sich so vorstellen, dass für jedes einzelne Bild ein oder mehrere Objekte
generiert werden, welche dann den „Körper“ der Flüssigkeit bilden.
233D Objekt bestehend aus mehreren Polygonen

24Gecachtes Mesh bezeichnet ein oder mehrere 3D Objekte, welche für jeden einzelnen
Zeitabschnitt innerhalb eines Zeitraums auf einen Datenträger geschrieben wurde.
Grundlagen 26
2.4 Cloth
Bei Stoffsimulationen handelt es sich meistens um die Erzeugung eines realistisch

wirkenden Kleidungsstoffverhaltens von diversen geometrischen Objekten (siehe
Abbildung 18). Auch die Berechnung sogenannter Softbodys fällt unter diese
Kategorie (siehe Abbildung 19).
Abbildung 18: Cloth Simulation
Abbildung 19: Softbodys
Die Kleidungsstoffsimulation sorgt für zusätzlichen Berechnungsaufwand, besonders

wenn es um animierte Charaktere geht, welche zum Teil schnelle Bewegungen
durchführen. Dabei kann es zu Interpenetrationen (gegenseitiges Durchdringen) der
Objekte kommen. Dies ist einer der Gründe, warum beim Charakterdesign darauf
geachtet wird, Kleidungen möglichst dicht an dem Körper des Charakters zu
entwerfen, um nicht erst Cloth Simulationen bei der Animation berechnen zu müssen,
oder wenn, dann nur geringfügige. Da während dieser Simulation eine Menge Daten
parallel verarbeitet werden können und die Berechnungen hauptsächlich aus
Vektoroperationen bestehen, sind diese sehr geeignete Kandidaten für die
Auslagerung auf parallele Vektorprozessoren, wie es bei der GPU der Fall ist.
Grundlagen 27
2.4.1 Berechnung
Für die Berechnung von weichen Materialien wurden im Laufe der Zeit mehrere
Methoden entwickelt. Derzeit sind drei Berechnungsmethoden verbreitet. Die genau
verwendeten Algorithmen der einzelnen Applikationen sind ein gut gehütetes
Geheimnis der einzelnen Physik Engines.
2.4.1.1 Geometrische Verfahren
Einer der Ersten, die sich mit dieser Thematik beschäftigen, war J. Weil, welcher
bereits 1986 ein Paper25 über Kleidungssimulationen für die damalige SIGGRAPH26
verfasste. Mittels dieser Methode konnte der Look eines Kleidungsstoffes erzeugt
werden. Dabei ging es noch nicht um die direkte realistische Simulation von
Kleidungsstoff-Eigenschaften, sondern lediglich um dessen Look.
Sie basiert dabei auf mehreren Abschnitten in denen geprüft wird, an welchen
Stellen sich Punkte im Mesh auf welche Art und Weise ausdehnen würden. Dabei
wird das Mesh als Erstes in ein Quadrat aufgeteilt, welches das Kleidungsstück
repräsentiert. Dieses wird anschließend in mehrere Dreiecke aufgeteilt. Von einem
Punkt des Dreiecks wird eine Seilkurve zum Mittelpunkt der Hypotenuse abgebildet.
Die Punkte auf dieser Seilkurve bestimmen nun die Verformung des Objektes (siehe
Abbildung 20).
25 J. Weil, The Synthesis of Cloth Objects, Computer Graphics, (Proc SIGGRAPH), Vol 20, No 4,
1986
26 SIGGRAPH, Kurzform für Special Interest Group on GRAPHics and Interactive Techniques, ist
eine jährliche stattfindende Konferenz über Computer Grafik.

Grundlagen 28
Für die Berechnung der Seilkurve verwendete J. Weil die folgende Gleichung:
𝑥−𝑏
𝑦 = 𝑐 + cosh
𝑎
Dieses Verfahren wird nun so häufig wiederholt, bis sämtliche Punkte mittels Seilkurve
abgebildet wurden. Dabei werden einzelne Punkte oftmals stark voneinander
verschoben, was sehr unnatürlich wirkt. Daher werden anschließend alle Punkte in
relativen Abständen zueinander betrachtet und in Relation gesetzt. Dies wird als
Relation Algorithm bezeichnet (Babic, 1999).
Abbildung 20: Geometrisches Verfahren

Grundlagen 29
2.4.1.2 Physikalische Verfahren
Bei den physikalischen Verfahren ist es möglich, nicht nur den Look, sondern das
Verhalten von unterschiedlichen Stoffen simulieren zu können. Dabei wird Mesh als
ein Set von Partikeln abgebildet (siehe Abbildung 21).
Für die Berechnung der Energieverteilung zwischen den einzelnen Partikeln und der
dadurch ausgelösten Positionsänderung gibt es unterschiedliche Algorithmen. Diese
beruhen auf der physikalischen Grundlage, dass jeder Körper im Zustand des
niedrigsten Energiepotenzials den er einnehmen kann, verharrt.
2.4.1.2.1 Feynman Algorithmus
C. Feynman hat nach Beobachtungen von Stoffen den Entschluss gezogen, dass
durch ihre Elastizität, einen Dehnungsfaktor und ihrer Dichte zu berechnen seien.
Aus dieser Erkenntnis hat er folgende Gleichung entwickelt:
𝐸 𝐸, =𝑘 𝐸 , +𝑘 𝐸 , +𝑘 𝐸 ,
ks - Elastizität
kb - Dehnung
kg - Dichte
Der Punkt, welcher das geringste Energiepotenzial besitzt, wird mit dem um ihn
herumliegenden Punkten verglichen. Dann werden diese Punkte so verschoben,
dass diese etwas von ihrer Energie an den ausgewählten Punkt übertragen. Dieser
Vorgang wird so lange wiederholt, bis alle Punkte über das gleiche Energiepotenzial
verfügen. Aushängende Stoffe lassen sich somit simulieren(Babic, 1999).
Grundlagen 30
2.4.1.2.2 Provot Algorithmus
Weiter verbreitet ist das Verfahren von Provot27 . Er modellierte Kleidung, indem er
Springs mit Constraints kombinierte. Dabei nutzte er die Newtonsche Dynamik und
verknüpfte diese mit internen Kräften zwischen den Punkten.
𝐹 (𝑖, 𝑗) + 𝐹 (𝑖, 𝑗) = 𝑚𝑎(𝑖, 𝑗)
M –Masse der Punkte P(i,j)

a(i,j) –Beschleunigung
Fint(i,j) –interne Kräfte am Punkt P(i,j)
Die internen Kräfte werden dabei folgendermaßen definiert:
𝑃, 𝑃 ,
𝐹 (𝑖, 𝑗) = − 𝐾 𝑃, 𝑃 , − 𝑃, 𝑃 ,
( , )∈
𝑃, 𝑃 ,
K – Härte der einzelnen Springs

R - Set von benachbarten Punkten
𝑃, 𝑃 , - Ursprungslänge der Punkte Pi,j und Pk,l
27 Benannt nach Xavier Provot

Grundlagen 31
Die externen Kräfte bestehen aus der Gravitation, einem Dämpfungsfaktor und der
Viskosität.
Die Funktionen dazu sind folgendermaßen aufgebaut.
Gravitation
𝐹 (𝑃 , ) = 𝑚𝑔
m -Masse
g -Beschleunigung
Dämpfung
𝐹 𝑃, = −𝑐𝑣 ,
c - Dämpfung Konstante
vi,j - Geschwindigkeit von Pi,j
Viskosität
𝐹 𝑃, = 𝑘 𝑁, ∗ 𝑢 −𝑣, 𝑛,
k - Viskosität Konstante
ni,j - Normale der Oberfläche des Punktes Pi,j
𝑢 - Flußgeschwindigkeit
Die Berechnung der einzelnen Punkte nach diesem Verfahren ist sehr zeitintensiv.
Daher wurden mehrere Optimierungen des Algorithmus entwickelt. Es wurde unter
anderem ein Multiresolution Verfahren von T. Le Thanh und A. Gagalowicz
entwickelt, welches diese Form der Berechnung um den Faktor 10 beschleunigen
kann.(André Gagalowicz, 2007)
Diese Form der Berechnung hat bis heute noch Verwendung in vielen Applikationen.
Sie werden allerdings nicht nur für die Simulation von weichen Körpern verwendet,
sondern insgesamt für die Generierung dynamischer Simulationen. So können diese z.
B. verwendet werden, um ein Kamerarig28 zu entwickeln, welches realistisch auf
Bewegungen reagiert und somit weniger Keys benötigt.
28 Aufhängung für eine Kamera

Grundlagen 32
2.4.1.3 Partikelenergie-basierte Verfahren
Partikelenergie-basierte Verfahren stellen die aufwendigste und modernste Methode

dar, um Kleidungsstoffsimulation zu berechnen. Dabei baut diese auf die vorher
beschriebene Methode auf und erweitert sie um mehrere Parameter. Hier wird das
Partikelnetzwerk als Ganzes betrachtet. Die einzelnen Partikel folgen den Gesetzen
der Kraftfelder, mit welchen sie gekoppelt sind (siehe Dynamische Felder).
Diese haben dabei mehrere Aufgaben. Zum einen die der Erhaltung der gesamten
Objektform und zum anderen zur Berechnung von Kollisionen. Dabei stellen die
einzelnen Springs einen Leiter dar, welcher Energie von einem Knotenpunkt zu einem
anderen überträgt.
Für die Berechnung physikalischer Verfahren sind folglich 2 Arten von Constraints
Voraussetzung. (NVIDIA, 2007)
Spring Constraint: Sie bilden Verbindungen zwischen den einzelnen Partikeln

und beschränken diese zueinander. Die einzelnen Springs nehmen über deren
einzelne Attribute Einfluss auf das Gesamtverhalten des Objektes. Sie sind
fundamental für jede Cloth Simulation und stellen damit den Grundstein dar.
Dabei ist ein Spring zwischen zwei Partikeln, a und b, durch ein Distanz
Constraint zwischen diesen definiert.
Collision Constraint: Sie dienen zur Kollisionserkennung von einzelnen Partikeln

mit deren Umgebung. Dadurch können Interpenetrationen vermieden
werden. Oftmals kommen weitere Attribute wie Kollisionsdistanz oder Radius
zur Verwendung.
Grundlagen 33
Die einzelnen Springs zwischen den Partikeln werden häufig in einer Kombination von
sogenannten Structural Springs und Shear Springs verwendet (siehe Abbildung 22).
Abbildung 21: Mesh mit Partikel
Abbildung 22: Structural Springs (links) und Shear Springs (rechts)

Grundlagen 34
Innerhalb von Maya werden diese Springs automatisch mit der Erzeugung eines
NCloth Objektes29 angelegt (siehe Abbildung 23). Die Verformung der einzelnen
Springs wurde in Abbildung 24 mittels Spring Constraint verdeutlicht.
Abbildung 23: NCloth Objekt mit Springs
Abbildung 24: Cloth Objekt mit Pin Constraint
29 Ein Maya Objekt, welches den Nucleus Solver von Maya verwendet.
Solver 35
3 Solver
Physik Engines, welche auch als Solver bezeichnet werden, stellen den Grundkern
der physikalischen Berechnungen dar. Sie beinhalten alle nötigen Berechnungs-
klassen, um realistisch physikalische Abläufe simulieren zu können. Diese Engines
wurden zwar nach den Maßstäben einer möglichst realitätsnahen Simulation
entwickelt, haben aber auf Grund dessen, dass sie für spezifische Einsatzgebiete
entwickelt werden, unterschiedliche Limitationen und Berechnungszeiten.
Logischerweise reicht die heutige Rechengeschwindigkeit im PC-Bereich noch nicht
aus, um detaillierte Echtzeitsimulationen laufen zu lassen. Daher wurden Algorithmen
entwickelt, welche die physikalischen Gesetzmäßigkeiten verallgemeinern und somit
einen realitätsnahen Look erzeugen sollen. Andere Bereiche, wie die der Baustoffe
oder Automobilindustrie beschäftigen sich natürlich weniger mit dem Look, sondern
vielmehr mit dem tatsächlichen Verhalten von Materialien während
unterschiedlicher Bedingungen. Diese Simulationen benötigen einen wesentlich
größeren Zeitraum und finden im Film oder Echtzeitgebiet kaum Anwendung,
weshalb auf solche Berechnungen während dieser Arbeit nicht eingegangen wird.
Solver 36
3.1 Echtzeit Engines
3.1.1 Ageia
Ageia ist eine amerikanische Firma, welche 2002 gegründet wurde und den PhysiX
Chip entwickelte. Dieser war auf die Berechnung von physikalischen Prozessen in
Spielen ausgelegt und viel schneller als die damaligen CPUs. Außerdem entwickelte
Ageia das Novodex SDK (später PhysX SDK), welches die Physikengine darstellte, die
den PhysX Chip nutzte.
Damit war Ageia die erste Firma, welche einen Chip zur getrennten Berechnung für
physikalische Prozesse auf dem Markt anbot.
Da dieser Chip hauptsächlich im Echtzeitbereich von Spielen nutzen fand, wurde

nach Spieleherstellern gesucht, welche die von Ageia entwickelte Engine in ihre
Spiele integrieren sollten. Da die zusätzliche Hardware aber kaum einen großen
Unterschied in Spielen ausmachte, war der Start sehr schleppend und ging sehr
langsam voran. Auch Hersteller, welche, den PhysiX Chip auf ihrer Hardware
integrieren sollten, waren noch sehr rar am Markt.
Schließlich kündigten größere Hersteller, wie NVIDIA und ATI die Entwicklung von
Physikchips an, was das Interesse am Markt weiter steigerte. Ein kostenloses Spiel mit
dem Namen „Cellfactor: Revolution“ wurde ebenfalls entwickelt, welches die PhysX
Engine nahezu komplett ausnutzte und Fluids und erweiterte ClothSim integriert
hatte. Dieses Spiel war so physiklastig, dass es ohne eine Physikkarte auf keinem
aktuellen PC fließend laufen konnte. Erst durch das Aufkommen immer neuerer
Spiele, und schließlich Cellfactor Revolution, wurden die Nachfragen bereits so groß,
dass NVIDIA auf Ageia aufmerksam wurde und die Firma schließlich am 13 Februar
2008 übernahm. Die eigentliche Engine wurde vor der Übernahme so abgewandelt,
dass keine weitere zusätzliche Hardware benötigt wird, sondern die zum großen Teil
ungenutzten Kapazitäten der GPUs ausreichen. So verschwanden die PPUs (physical
prozessing unit) relativ schnell wieder vom Markt und sind heute nur noch in
Tauschbörsen erhältlich.
Die Engine trägt seit der Übernahme durch NVIDIA nun die offizielle Bezeichnung
NVIDIA PhysX und stellt die zurzeit am weitesten entwickelte Physik Engine für
Echtzeitanwendungen dar.(NVIDIA, 2008)
Solver 37
3.1.2 Havok physics
Die Havok physics wurde von einer irischen Firma namens Havok entwickelt und stellt
aus heutiger Marktsicht im Echtzeitbereich noch immer das direkte
Konkurrenzprodukt zu NVIDIA´s PhysX dar.
Havok erkannte im Laufe der Zeit die Begrenztheit der Berechnungsgeschwindigkeit

auf der CPU und wagte sich in neues Territorium. Denn Havok entschloss sich im
Gegensatz zu einer eigenen Chipentwicklung, wie es damals bei Ageia der Fall war,
für eine modifizierte Engine, welche direkt auf den bereits vorhandenen Grafikkarten
ausgeführt werden konnte. So wurde 2006 die erste Version von Havok FX in
Zusammenarbeit mit NVIDIA entwickelt. Im September 2007 wurde Havok von Intel
übernommen und die offizielle Weiterentwicklung von Havok FX eingestellt.
Intel wollte die Engine anschließend an ihre Prozessoren anpassen und somit die
Effizienz der Nutzung der CPU verbessern. Die Weiterentwicklung der Engine liegt
zurzeit mehr oder weniger auf Eis, auch wenn weiterhin viele Spiele mit ihr produziert
werden.
Soweit bekannt ist, haben sich Intel und AMD geeinigt bei der Weiterentwicklung der
Havok Engine zusammenzuarbeiten und für 2009 wurden die ersten
Grafikprozessoren von Intel ( Larrabee ) angekündigt. Daher ist nun abzuwarten, ob
Intel die Havok FX Engine wieder weiterentwickeln lassen wird. (Telekinesys Research
Ltd, t/a Havok, 2009)
Solver 38
3.2 Offline Engines
Offline Solver stellen keinen Anspruch an die Echtzeitfähigkeit und können somit
komplexere Berechnungen absolvieren. Dabei werden die einzelnen Schritte der
Berechnung meistens in externe Daten ausgelagert. Dieser Vorgang wird als das
Cachen bzw. Baken von Simulationen bezeichnet.
Diese Daten können nun auf andere Systeme kopiert werden, wodurch sich die
berechnete Simulation verteilen lässt. Dies ist besonders wichtig für das spätere
Rendering, bei dem jeder Computer die exakt gleichen Simulationsdaten benötigt.
Das eigentliche Berechnen einer Simulation lässt sich nicht auf mehrere PCs verteilen.
Da jeder Berechnungsschritt aufeinander aufbaut, ist es nicht möglich, dass ein PC
den nächsten Schritt berechnen kann, ohne den vorherigen zu wissen. Für
komplexere wissenschaftliche Simulationen von physikalisch korrekteren Systemen
kommen sogenannte Supercomputer zum Einsatz, bei denen ein Computer die
Berechnungskapazität mehrerer PCs besitzt. Aktuelle Softwarelösungen bieten
oftmals mehrere Solver innerhalb eines Paketes an30. Außerdem ist es oftmals möglich
weitere Physik Engines in ein System zu integrieren31.
30Maya verfügt über mehre Solver und erweitert diese von Version zu Version.
31Für Kleidungssimulationen wird oft der Solver von SYFLEX verwendet, welcher als nahezu in
jedes 3D System integriert werden kann. Auch die PhysiX Engine lässt sich in Maya integrieren.
Entstehung des Films: With Flow 39
4 Entstehung des Films: With Flow

4.1 Der Anfang
Anhand des Kurzfilmes „ With Flow“ werden nun die Ergebnisse dargestellt.
Aufbauend auf die vorangegangenen Ausführungen können nun konkrete 3D
Testfälle erschaffen werden.
Der erste Schritt bestand darin, geeignete Testszenarien zu entwickeln, in denen die
wichtigsten Kombinationsmöglichkeiten von Stoffen und Flüssigkeiten zum Einsatz
kamen. Während dieser Phase wurden grobe Setups getestet, die ein erstes Gefühl
für anschließende Animationen bildeten.
Ebenfalls wurde sehr viel Referenzmaterial studiert, um ein besseres Bild von der
Physik von komplexen Strömungen zu gewinnen.
Bis zu diesem Zeitpunkt gab es noch keine genaueren Vorstellungen über den Ablauf
oder die einzelnen Testfälle.
Nach etwas Planung stand fest, dass folgende Szenarien umgesetzt werden.
Partikeltests
• Diverse Feldertests
• Interaktion mit anderen Körpern
• Schwarmverhalten
Fluids
• Brunnen
• Umfallender gefüllter Körper z. B. ein Weinglas
• Korridorflutung mit weiteren Objekten
• Ozean
• Gas- und Rauchberechnung
Kleidungsstoffe
• Aufgerollten Stoff, aushängen lassen
• Fall und Flug von Papierstücken
• Stoffe und Wind
• Zerreißender Stoff
• Softbody-Bälle
In Absprache mit Herrn Bremer wurde sich dafür entschieden, die einzelnen Testfälle
in einen zusammenhängenden Film zu fassen.
Es wurde dafür, ein von der HTW entwickeltes 3D Modell, welches einem Hinterhof
entsprach, zur Verfügung gestellt. Durch die Abwandlung von reinen Testszenarien in
einen zusammenhängenden Kurzfilm wurde eine neue und wesentlich größere
Herausforderung geschaffen.
Die folgenden Wochen wurde das Grobkonzept für die Geschichte entwickelt.
Dabei wurde darauf Wert gelegt, die Simulationen in einem zusammenhängenden
Kurzfilm zu kreieren, bei dem es nicht auffallen sollte, dass es sich eigentlich um Fluid-
und Clothtests handelte.
4.2 Planungsphase
Im Rahmen eines Praktikums innerhalb einer Post-Production Firma wurden bereits im

Vorfeld unzählige und wertvolle Erfahrungen betreffend der Produktion von 2D- und
3D-Animationen gesammelt. Diese unterscheiden sich in ihrer wesentlichen
Durchführung kaum von Kurzfilmen oder Langspielfilmen. Dort wurden viele Schritte
verwendet, welche beim Aufbau einer Pipeline32 zu beachten sind. Außerdem
wurden viele Produktionsberichte von größeren Firmen studiert, welche oftmals im
Internet veröffentlicht wurden.
Eine klassische Produktions-Pipeline umfasst folgende Schritte:
• Entwicklungsphase:
Dies ist die Anfangsphase, in der die Elemente, welche die Produktion einleiten,
inspirieren und weiterführen, kreiert, gesammelt und organisiert werden. Diese
umfassen Skripts, Storyboards, Referenz Material, Characterdesigns und Material zur
Stilentwicklung.
• Pre-Production:
Hier werden Elemente erstellt, welche im Film verwendet werden. Dies sind im Prinzip
die Puzzleteile der Produktion. Unter anderem sind dies 2D und 3D Animatics, 3D
Models der Charaktere und Requisiten, Texturen, Rigs und Stimmaufnahmen.
• Shot Production: In dieser Phase werden die einzelnen Einstellungen (auch Shots
genannt) geblockt, animiert, beleuchtet, gerendert und dann im Compositing
zusammengefügt. Mit anderen Worten werden hier die gesammelten und erstellten
Puzzleteile zu einem Ganzen zusammengestellt.
• Post Production. Dies ist die letzte Optimierungsphase. Hier werden einzelne
Puzzleteile, retuschiert, umgeordnet oder rausgeschnitten. Oftmals wird das
Compositing zu Post-Produktion gezählt. Vermarktung und Distribution zählen
ebenfalls zur Post-Production.
32 Pipeline steht in diesem Kontext für einen genauen Ablaufplan.

4.2.1 Sicherheit
Oft unterschätzt und doch sehr wichtig ist das gesunde Arbeiten während eines so
großen Projektes. Bedingt durch den Arbeitsaufwand an diesem Kurzfilm waren
durchschnittlich 15 Stunden Arbeitszeit pro Tag an einem Computer geplant.
Aufgrund des hohen Stundensatzes, welcher konstant für 3 Monate gehalten werden
musste, war es abzuwarten, wie hoch der gesundheitliche Preis dafür sein würde. Es
wurde fest eingeplant, dass im Laufe des Projektes die Konzentration sinken wird und
mehr und mehr Fehler entstehen. Der Schlafrhythmus wurde dabei hauptsächlich
durch Renderzeiten und Simulationszeiten definiert, nach denen der Wecker gestellt
wurde.
Um sicherzustellen, während der Arbeit geistig fit zu bleiben, wurden während des
Projektes die folgenden Erfahrungen gesammelt.
4.2.1.1 Ernährung
Die Ernährung wurde möglichst ausgewogen und bewusst geführt. Besonders bei
längeren Arbeitsstunden wurde darauf geachtet, nicht das regelmäßige Essen zu
vernachlässigen. Während dieser Arbeit wurden kein Kaffee oder sonstige
aufputschende Stoffe konsumiert. Eine gute Hilfe zur Konzentrationsverbesserung
stellte medizinischer Sauerstoff dar, welcher bei erhöhter Konzentrationsschwäche
inhaliert wurde.
4.2.1.2 Schlaf
Der regelmäßige Schlafrhythmus fehlte dem Körper. Daher dauerte es nicht lange,
bis die ersten Schlafstörungen einsetzten. Es gibt viele Techniken, die zum schnelleren
und effektiveren Einschlafen verwendet werden können. Als angenehmste Methode
stellte sich dabei Hypnose heraus, die vor jedem Schlaf angewendet wurde. Auch
autogenes Training war sehr hilfreich, wobei hier mehr Aktivität von einem selbst
abverlangt wird, weswegen später hauptsächlich Hypnose zum Einsatz kam.
4.2.1.3 Sport
Die ersten 3 Wochen während dieser Arbeit wurden keine größeren körperlichen
Aktivitäten durchgeführt, was zu einem antriebsloseren Zustand führte. Bewegung ist
sehr wichtig, wenn man geistig aktiv bleiben will. Also wurden 6 Stunden Sport pro
Woche, von dem Schlaf abgezogen und diverse Sportangebote der HTW gebucht.
4.3 Entwicklungsphase
Um sicher zu gehen, was überhaupt in der kurzen Zeit möglich ist, wurde ein genauer
Plan entwickelt, wie jede einzelne Kamerafahrt und das Blocking33 der einzelnen
Elemente aufgebaut wird. Innerhalb einer Woche wurde das erste grobe
Grundmodell aller Szenen und deren einzelnen Shots angefertigt. Anschließend
entstand daraus das erste Animatic34 des Films.
Aus den einzelnen Einstellungen und deren Dauer wurde der ungefähre Aufwand
abgeleitet sowie die ersten Überlegungen getroffen, an welchen Stellen sich
zusätzlicher Aufwand einsparen lässt oder welche Szenarien sich vereinfachen lassen.
So entwickelte sich das erste zeitliche Fenster, welches in eine Excel Tabelle gefasst
wurde.
4.3.1 Produktions -Pipeline
Die Produktions-Pipeline für den Kurzfilm musste sehr genau durchdacht werden, was
innerhalb der ersten Planungswochen geschah.
Die Nutzung der zur Verfügung stehenden Ressourcen war dabei ein
ausschlaggebender Faktor. Ohne die Verfügung einer Renderfarm35 wären ebenfalls
andere Entscheidungen bezüglich des Formates getroffen worden.
Die Entscheidung auf 1080p zu rendern, kam mit der Zusage über die Verwendung
von 2 Laboren mit jeweils 21 Rechnern.
Sämtliche physikalischen Berechnungen wie Cloth und Fluids wurden während des
Arbeitens auf einem weiteren Computer berechnet. Jeder Tag, an welchem keine
Berechnungen stattfanden, stellte verlorene Zeit dar. Deshalb wurde bereits, bevor
die eigentliche Geschichte und das Animatic fertig waren, versucht, die ersten
Berechnungen zu starten.
Die rechenintensivste Simulation stellte dabei die Kellerwelle(siehe 4.4.10.1) durch

den Korridor dar, weshalb mit dem Setup dieser Welle als erstes begonnen wurde.
Während des kommenden Monats wurde am Gesamtfilm gearbeitet und parallel

dazu die Partikelsimulation berechnet.
Da diese Simulation einen Monat Berechnungszeit benötigte, wäre sie zu einem

späteren Zeitpunkt nicht mehr möglich gewesen.
33 Bezeichnet die Komposition der einzelnen Elemente zueinander innerhalb des Bildes.
34 Erste Version einer Filmidee in Form von animierten Bildern
35 Ansammlung mehrerer PCs, welche von einem Server aufgaben zugeteilt bekommen.
4.3.2 Projekt Pipeline
Der nächste Schritt bestand darin, eine Pipeline zu entwickeln, die genau auf das
Projekt ausgelegt ist. Durch das Zusammenspiel der unterschiedlichen
Softwarepakete musste vorher eine genaue Struktur geschaffen werden, wie mit
welchen Daten umgegangen werden soll.
So wurde die Struktur folgendermaßen aufgebaut:
Abbildung 25: Aufbau der Datenstruktur

Diese Struktur machte es möglich, sehr effizient zwischen unterschiedlichen

Anwendungen zu wechseln, ohne den Überblick bezüglich der enormen
Datenmenge zu verlieren.
Dabei beinhaltet jedes Element weitere Untergruppen, welche anwendungs-
spezifisch gewählt wurden.
Ein weiterer wichtiger Aspekt ist eine korrektes Tagging36 für die unzähligen Dateien,
die im Laufe des Projektes kreiert werden. Man sollte auf den ersten Blick wichtige
Informationen wie Szene, Version, Dateityp, etc. ablesen können.
Die einzelnen Namensabschnitte sollten lang genug sein, aber eindeutig und kurz
genug, um handlich zu bleiben:
• zu lang: Scene01_Shot3_dynamic_testing_Version03.ma
• zu kurz: s01_s3_dt03.ma
• genau richtig: s01_sht03_dyn_03.ma
Generell ist es ratsam, jedem nur erdenklichen Element während der Produktion
einen eindeutigen Namen zuzuweisen. Dies fängt bei Ordnerstrukturen an und geht
bis zu den einzelnen Ebenen im Compositingprogramm.
Folgende Aufgaben standen jetzt noch bevor:
Pre-Production
• Modellieren von Objekten und Umgebung
• Texturieren
• Charakter Rigging
• Aufbau einer Renderfarm
Shot-Production
• Animation
• Simulation
• Beleuchtung
• Rendering
Post-Production
• Compositing
• Vertonung
• Finaler Schnitt
36 Namensvergabe an Objekte
Während die Abarbeitung der einzelnen Schritte voranschreitet, muss man ein
System aufstellen, welches einem den Fortschritt übersichtlich vor Augen hält. Eine
sehr einfache Methode ist eine Tabelle, in der man nach und nach die einzelnen
fertigen Schritte farbig kennzeichnet. Bei der Abarbeitung der Shots kann man drei
verschiedene Vorgehensweisen anwenden, welche im Englischen als straight ahead,
Heroshots und Layering bezeichnet werden. Die meiste Zeit wird während dieser
Arbeit dabei nach dem Heroshot-Prinzip gearbeitet, wobei versucht wird, möglichst
wenig Zeit für Elemente, die sich außerhalb des Zuschauerfokus befinden, zu
investieren.
Für die Gesamtübersicht wird mittels Excel-Tabelle die Stundenanzahl der einzelnen
Aufgaben abgeschätzt, außerdem wird innerhalb der Tabelle eine Anzahl der noch
verbleibenden Stunden und der noch zu benötigenden Zeit angezeigt. Nachdem
eine Aufgabe erledigt ist, wird diese aus der Tabelle abgehakt und automatisch von
der noch zu benötigten Zeit abgezogen. Auf diese Weise kann genau festgestellt
werden, ob der zeitliche Rahmen eingehalten wird.
Dabei wird jeder Wochentag bis zur Abgabe mit mindestens 10 Stunden Arbeitszeit
pro Tag geplant.
Außerdem wurde Protokoll darüber geführt, wieviel Zeit wirklich für einzelne
Aufgaben benötigt wird.
Während der Abarbeitung der einzelnen Aufgaben durfte der eingeplante

Zeitrahmen nicht überschritten werden. Dadurch mussten sehr häufig Kompromisse
bei Dingen eingegangen werden, die einfach abgebrochen werden mussten, da sie
zu viel Zeit beanspruchten. Man kann sich innerhalb von Maya sehr schnell in sehr
winzige Details verlaufen, die später kaum wahrnehmbar sind. Es war keine Zeit um
Testcompositings der Szenen anzufertigen, wodurch die Selektierung von Details,
welche wirklich notwendig sind, etwas schwerer viel.
4.3.3 Renderfarm
Die nächste Herausforderung bestand darin, eine netzwerkbasierte Lösung zu

integrieren, durch welche sich die diversen Renderaufgaben möglichst effizient auf
andere Workstations verteilen und berechnen lassen.
Nach Absprache mit Professor Bremer wurden 2 Labore zur Verfügung gestellt, in
welchen die dazugehörigen Workstations für diese Arbeit verwendet wurden.
Zu Beginn der Umsetzung wurde ein erster Überblick über die verschiedenen
Lösungen und deren Kosten und Funktionen verschafft.
Dazu wurde mit mehreren Firmen Kontakt aufgenommen, welche bereits eine
Lösung implementiert hatten, sowie Hersteller von Softwarelösungen direkt
kontaktiert.
Außerdem musste ein Plan entwickelt werden, wie die Infrastruktur der Labore und
Server modifiziert werden kann, um ein gemeinsames Arbeiten mehrerer Rechner
innerhalb eines Projektbaums zu gewährleisten(Peter Sloot, 1998).
4.3.3.1 Ist Zustand
Zum internen Netz gehören mehrere Schulungsräume, welche von einem Server
gesteuert werden. Die Räume sind physikalisch voneinander getrennt und über einen
Switch mit 1000-MBit Ethernet verbunden. Innerhalb der Räume besteht ein
homogenes 1000-MBit-Netzwerk, welches ausschließlich mit Windows XP arbeitet,
während die Server auf Linux Basis laufen. Der Anmeldeserver der Domain AI
befindet sich auf dem Gelände Wilhelminenhof, während sich der Fileserver
(Oberon) der Benutzeraccounts im Rechenzentrumbefindet. Diese übernehmen die
Aufgaben der Benutzerauthentifizierung mittels Active Directory sowie die
Adressenzuweisung über DHCP und Adressenübersetzung via NAT. Alle Räume
verfügen über Wireless LAN, also über einen zusätzlichen Access Point, der mit dem
jeweiligen Switch verbunden ist. Zusätzlich verfügt jeder Schulungsraum-PCs über die
interne Firewall von Windows XP.
TALK / DATA
TALK / DATA TALK RS CS TR RD TD CD
TALK RS CS TR RD TD CD
A B C D E F G H
A B C D E F G H
SELECTED
SELECTED
ON-LINE
ON-LINE
Abbildung 26: Ist Zustand Renderfarm

4.3.3.2 Soll Konzept
Das Ziel dieser Arbeit ist es, eine Renderfarm und Managementlösung in die
Produktionsumgebung zu integrieren, bei der die Möglichkeit gegeben wird,
Aufträge extern über das Internet auf die vorhandenen Rechner zu verteilen oder
gerenderte Bilder zu überprüfen. Es wird auf einem vorhandenen Schulungsraum-PC
eine Server Applikation und auf allen weiteren PCs die Client Software installiert und
konfiguriert. Anschließend wird mit einem Remotezugriff über das öffentliche Netz
eine Verbindung zur Server Applikation hergestellt und es werden Aufgaben an alle
Clients verteilt.
4.3.3.3 Analyse vorhandener Systeme
4.3.3.3.1 Mental Ray® Satellite
Mental Ray® Satellite ist eine mit Maya mitgelieferte Lösung, welche das
unkomplizierte Netzwerkrendern innerhalb von Maya ermöglichen soll. Die Idee
dieser Technologie besteht darin, dass jedes Bild in einzelne Blöcke zerlegt wird,
welche jeweils einen separaten Prozess darstellen. Damit lassen sich diese Blöcke auf
die einzelnen CPUs auslagern und im Netzwerk verteilen. Mental Ray® in Maya 2009
Unlimited unterstützt dabei bis zu 8 Cores, welche sich intern oder im Netzwerk
befinden können. Damit stellt diese Technologie die Ausnahme zum gewöhnlichem
Netzwerkrendering dar, denn sie ermöglicht das berechnen einzelner Bilder auf
mehreren PCs, während die meisten Lösungen jeweils mehrere Bilder pro PC zuteilen.
Mental Ray® Satellite hat außerdem den Vorteil, dass es sehr leicht zu konfigurieren
ist und keine weitere Software eingekauft werden muss(mental ray - Functional
Overview, 2007).
4.3.3.3.2 Konfiguration
Wie bereits erwähnt, ist die Konfiguration von Mental Ray® Satellite sehr einfach, da
es in Maya integriert ist. Dabei muss auf den Rechnern nur die Satellite-Client-
Software installiert und die nötigen Ports freigeben, welche sich aus der
„Windows\system32\Services” ablesen lassen.
Wenn die Clients installiert sind, genügt es die render.exe von Maya mittels Tag37 die
zu verwendenden Clients mitzuteilen, um die Berechnung der Bilder zu verteilen.
Weiterhin ist es möglich unter „User\prefs\mray.host“ eine Datei anzulegen und die
zu nutzenden Clients und Ports in diese einzutragen. Dies bietet den Vorteil, die
Satelliten innerhalb von Maya verwenden zu können. Beim Aufruf der render.exe
mittels Tag, wird die mray.host Datei ignoriert, während beim Auslassen des Tags
immer überprüft wird, ob sich Satelliten in ihr befinden.
37 Ein Tag ist ein Argument, welches an das Programm weitergeleitet wird.
4.3.3.3.3 Tests
Mental Ray® stellte für mich die einfachste und schnellste zu konfigurierende
Plattform dar, weshalb diese als Erstes implementierte wurde.
Während der Installation der Satelliten auf 10 PCs, wurden deren IP und Ports in die
„maya.rayhosts“ Datei eingetragen. Nach diversen Tests musste dagegen folgendes
festgestellt werden:
Beim Rendering auf einem bis zwei Maschinen konnte Mental Ray® Satellite
problemlos eingesetzt werden und die Renderzeit sank nahezu proportional ab.
Mit der Auslagerung der Berechnungen auf einem 3. PC fingen die ersten Probleme
an, welche deutlich machten, warum diese Lösung für das Vorhaben absolut
unbrauchbar ist.
Es konnte nicht in Erfahrung gebracht werden, ob diese Probleme durch Mental
Ray® oder dessen schlechter Implementierung innerhalb von Maya auftraten. Es war
unmöglich auf 3 Rechnern ein einziges Bild zu berechnen, welches auf einen
einzelnen PC circa 15min in Anspruch nahm.
Die Software ist zwar in der Lage zu erkennen, wenn es Probleme gibt, weil ein Block
nicht berechnet wird oder ein Client ausfällt, dennoch wird dadurch der komplette
Vorgang abgebrochen.
Falls also ein Client ausfällt, ist die Software nicht in der Lage den fehlenden Teil auf
die weiteren Maschinen zu verteilen oder das Bild auf den noch laufenden Clients
fertig zu rendern. Beim Rendern einer Bildsequenz bricht der komplette Vorgang ab,
wenn es irgendwo einen kleinen Netzwerkfehler gibt. Wird der Rendervorgang
innerhalb von Maya unterbrochen, führt dies sogar oftmals zum kompletten Absturz
der Software.
4.3.3.3.4 Back Burner
Back Burner ist ein freier Rendermanager, welcher von Autodesk bei 3D Studio Max
oder Flame Systemen mitgeliefert wird.
Back Burner unterstützt offiziell noch nicht Maya. Es gibt aber dennoch mehrere
inoffizielle Maya Mel Skripte, welche ein verteiltes Rendering innerhalb von Maya auf
der Plattform von Burner ermöglichen sollen. Keine der gefundenen Skripte konnten
zum Laufen gebracht werden. Der Support dieser lag oftmals im fremdsprachigen
Raum.
4.3.3.3.5 Dr. Queue
Dr. Queue ist ebenfalls eine freie Renderlösung. Der Support ist hier sehr schlecht und
das Projekt wurde vor 2 Jahren nahezu eingestellt. Da keine ausführbaren Daten von
diesem Projekt zur Verfügung stehen, muss man den Quellcode für die Windows x32
Umgebung kompilieren. Dies führte erneut zu mehreren Fehlern, die zwar bekannt
waren, aber zu denen keine Antwort existierte. Aus mangelnder Zeit wurde die
Energie der Arbeit wieder auf das eigentliche Projekt gelenkt.
4.3.3.3.6 Royal Render
Royal Render von der Firma Binary Diversity stellt eine der günstigsten und
komfortabelsten Lösungen dar. Es ist die einzige Lösung, welche ich bereits
erfolgreich in Anwendung gesehen habe und mit welcher ich arbeiten durfte. Dabei
wird die Software ständig weiterentwickelt und bietet einen guten Support. Sie hat
einen guten Funktionsumfang und liegt im unteren Preisbereich.
Das Prinzip funktioniert hier folgendermaßen:
Es wird ein Ordner im Netzwerk verwendet auf den alle Rechner zugreifen können.
In diesen Ordner muss die Software installiert werden. Anschließend werden die
Updates installiert.
Nun kann die Server.exe von dem Rechner gestartet werden, welcher als Server
fungieren soll.
Alle anderen Clients müssen nur die Clients.exe von diesem Netzlaufwerk starten und
tragen sich dabei beim Server ein.
Als Nächstes können Client und Server als Hintergrunddienste installiert werden.
Der Benutzer benötigt dafür lokale Administratorrechte und kann während der
Installation angelegt werden.
Anschließend sorgt der Hintergrunddienst für die Ausführung der Client.exe oder
Server.exe. Somit lassen sich die Geräte direkt nach dem Hochfahren für das
Rendering verwenden, ohne jegliche Benutzereingaben tätigen zu müssen.
Die Clients senden ständig ihren Status, welcher unter anderem deren CPU Last,
RAM-Auslastung oder Bereitschaft signalisiert.
Ist ein Client gerade in Verwendung durch ein weiteres Programm, so kann vom
Server aus entschieden werden, ob dieser Client für das aktuelle Rendering
verwendet werden darf. Standard sind hierbei 3Minuten, nachdem keine weiteren
Aktivitäten stattfanden.
4.3.3.4 Wahl der Renderlösung
Alle Hersteller bieten ihre Softwarelösungen für Windows, Unix und teilweise auch für
Macintosh an. Die Clients und Server sind bei jedem Hersteller in einer kostenlosen
freien und einer erweiterten kostenpflichtigen Version verfügbar. Dabei beschränken
sich die meisten Hersteller bei der frei nutzbaren Version auf ein System, bei dem eine
Serverapplikation nur zwei weitere Nodes verwalten kann.
Als Softwarelösung kam Royal Render zum Einsatz.
Dazu musste die Software auf einen Fileserver übertragen werden, welche von allen
Workstations erreichbar ist. Nach Absprache mit dem Netzwerkadministrator Michael
Baltsch haben wir eine externe Festplatte mit Netzwerkzugang eingerichtet, auf dem
der „rr_User“ innerhalb des HTW Netzwerkes Zugriff hat.
Da wir mit mehr als 10 Nodes gleichzeitig auf dieses Netzlaufwerk zugreifen mussten,
war es ausgeschlossen, eine normale Windowsfreigabe einzurichten, da eine
Freigabe für mehr als 10 Verbindungen erst in den Servervarianten von Windows
verfügbar ist.
Der bestehende Server Oberon kam ebenfalls nicht als Fileserver infrage, da sich
nach mehreren Tests die Verbindung als sehr instabil zeigte.
Die Infrastruktur wurde daraufhin folgendermaßen entwickelt:
Jeder Client hat einen lokalen Nutzer rr_User, welcher über die nötigen lokalen
Rechte verfügt. Außerdem hat dieser User Zugriff auf den für ihn freigegebenen
Ordner auf dem Fileserver.
Nachdem der Rechner gestartet ist, wird durch einen Hintergrunddienst automatisch
die Client.exe gestartet, welche sich ebenfalls auf dem Fileserver befindet. Diese
meldet sich anschließend beim Server, worauf dieser erkennt, dass ein Client online
ist und eventuell für das Berechnen eingesetzt werden kann.
Ob ein Client für das Rendern verwendet werden kann hängt von seinen Settings ab.
Diese können individuell nach Inaktivität oder Projektzuordnung gesetzt, aber auch
vom Server überschrieben werden. Es ist also möglich alle Clients zum Rendern zu
zwingen, auch wenn auf ihnen gerade gearbeitet wird. Die Implementierung der
Renderumgebung mittels Royal Render verlief weitestgehend problemlos und die
Firma reagierte schnell auf Fragen. Nachdem ein Bug innerhalb der Rendersoftware
gefunden wurde und mit dem dazugehörigen Entwickler Kontakt aufgenommen
war, wurde der Bug innerhalb von 3 Tagen beseitigt.
Anschließend lief die Arbeit mit Royal Render problemlos.

4.3.3.5 Installation
Als Fileserver wurde als Erstes der Hauptrechner Ananke1, welcher als Royal-Render-
Server diente verwendet. Dazu wurde die Software innerhalb eines lokalen Ordners
installiert, welcher per Netzwerkfreigabe von allen Clients erreichbar war.
Anschließend wurde die Clientsoftware installiert. Da Windows XP nur 10 gleichzeitige
Netzwerkfreigaben zulässt, konnten sich jeweils 10 PCs verbinden, während der 11.
keine Verbindung bekam.
Zu dem damaligen Zeitpunkt bestand noch die Annahme, dass sich diese Limitierung
mittels gepatchter tcpip.sys überwinden ließe. Nach dem Patchen38 wurde
festgestellt, dass es für Freigaben keinen Unterschied machte. Also brauchte man
einen Fileserver.
Da Royal Render gerademal 30 Megabyte verwendete, war die nächste Idee, den
vorhandenen Oberon Samba Fileserver der HTW zu verwenden.
Nachdem Royal Render auf dem Oberon Server installiert war und alle Clients sowie
der Server korrekt liefen, fiel auf, dass einige Clients vom Server als inaktiv angezeigt
wurden.
Also wurden die Logfiles des Clients geprüft und es wurde diagnostiziert, dass diese
durch ein Übertragungsproblem keinen Zugriff auf den Server hatten. Beim Testen
mehrerer Neustarts der Clients und des Servers verlief die Verbindung zum Oberon
Server sehr instabil.
Es war kein erkennbares Muster zu finden, nachdem die Clients ausfielen und als
nach mehreren Neustarts sogar der Server mit einer Netzwerkfehlermeldung
abstürzte, musste eine andere Lösung gefunden werden.
Der betreuende Netzwerkadministrator stellte eine externe Festplatte mit integriertem
Linux Fileserver zu Verfügung.
Wir errichteten eine neue Freigabe auf der Netzwerkfestplatte, was eine
Neuinstallation sämtlicher Clients und deren Server notwendig machte. Gleich zu
Beginn der ersten Clientstarts kam eine Fehlermeldung, dass diese sich nicht in die
Serverliste eintragen können. Nach einiger Recherche wurde herausgefunden, dass
eine zeitliche Einschränkung die Dateien für weitere Zugriffe blockierte.
Dies konnte im Webinterface der externen Festplatte deaktiviert werden. Nun war
die Renderfarm einsatzbereit.
38 Als Patch wird ein kleineres Softwareupdate bezeichnet.

4.3.3.6 Remotezugriff
Abbildung 27: Remotezugriff Zugriff auf die Farm
Der nächste Schritt war die Implementierung einer Infrastruktur, welche die Kontrolle
von außerhalb gewährleisten sollte.
Dafür wurde der installierte Royal Render Server um einige Funktionen erweitert.
Zuerst wurden die Remoteports bei der Firewall freigeschaltet und anschließend der
von Windows integrierte Remotedesktop aktiviert.
Da ein lokaler Benutzer mit Administratorrechten existierte, wurde diesem außerdem
die Berechtigung zur Remotedesktop-Verwendung erteilt. Erste anschließende Tests
verliefen erfolgreich.
Das einzige Problem, welches vorerst noch herrschte, lag in der
Netzwerkkonfiguration des Servers. Anfangs brach die Verbindung alle paar
Sekunden ab, da sich der Rechner nicht richtig authentifizieren konnte und ständig
neue Authentifizierungsversuche unternahm, wobei eine kurze Unterbrechung
stattfand.
Der Remotedesktop war daher die ersten paar Tage extern kaum nutzbar und für
diesen Zeitraum kam eine weitere freie Remotelösung namens TightVNC zum Einsatz.
Nachdem dieser Fehler behoben war, konnte extern wunderbar auf den Server
zugegriffen und dieser gesteuert werden.
Der nächste Schritt bestand darin, neue Daten wie Texturen oder Szenen von zu
Hause aus auf den Server zu übertragen.
Dafür wurde der Filezilla FTP Server auf dem Royal Render Server installiert und
konfiguriert.
Hier wurde ein spezieller Nutzer angelegt, welcher nur auf den Projektordner Zugriff
hatte.
4.3.3.7 Überprüfen der gerenderten Bilder
Der letzte Schritt war die Einrichtung eines Systems, mit welchem sich die
gerenderten Bilder überprüfen und gegebenfalls verwerfen oder neu rendern lassen.
Das Überprüfen der Bilder nach ihrer korrekten Datenstruktur ist ein relativ einfacher
Prozess, welcher sich automatisieren lässt. Das Überprüfen der Bilder auf eventuelle
Renderfehler oder falscher Settings dagegen ist ein Prozess, welcher manuell
durchgeführt werden muss. Solche Fehler können mehrere Ursachen haben und von
Lichtfehlern, bis hin zu internen Maya oder Mental Ray® Fehlern führen. Daher muss
jedes gerenderte Bild genau betrachtet und ausgewertet werden.
Um frühzeitig eventuelle Fehler zu erkennen und zu beheben, geht man
stichprobenartig durch die gerenderten Bilder.
Dabei erwies sich die Standard Remotedesktop Verbindung als nicht ausreichend,
denn sie ist nicht für größere Bilddaten ausgelegt. Um trotzdem eine genaue
Aussage über fehlerhafte Elemente treffen zu können, verwendet man eine Funktion
des Royal Render Server , welche es erlaubt, eine Übersicht der bisher gerenderten
Bilder und Projekte als HTML zu generieren. Als Webserver dafür kam Tinyhttp zum
Einsatz.
Nun war es möglich von zu Hause aus, den Server steuern, neue Daten hochzuladen
und gerenderte Bilder überprüfen.
4.3.3.8 Netzwerkauslastung
Bei einer Auflösung von 1920x1080 hatten die einzelnen Bilder eine Größe von über
sieben Megabyte. Jedes Bild wurde dabei nochmals in mindestens 7 Pässen
gerendert, was einem Datenvolumen von 7x7 Megabyte, also ca. 50 Megabyte pro
Frame entsprach.
Wenn 40 PCs alle 30 Minuten ein Frame auf den Server kopieren, so ergeben sich
ungefähr 2 Gigabyte innerhalb von 30min.
Innerhalb eines 1000-MBit Netzwerks, entsprechen 2GB innerhalb von 30min ca. 1.8
MB/sec, was theoretisch kein Problem darstellen sollte. Problematisch wird es nur,
wenn alle 40 Rechner zur gleichen Zeit eines Bildes fertig gerendert haben und
hochladen. Dann steht die Verbindung förmlich still. Dieses Problem kann man
vorbeugen, indem Verzögerungen aktiviert werden, wobei jeder Rechner um eine
Minute versetzt startet. Außerdem wurden die Labore so aufgeteilt, das sie
unterschiedliche Shots renderten, was ebenfalls einen unterschiedlichen Zeitaufwand
darstellte.
Das Übertragen der Bilder auf den Fileserver konnte dadurch problemlos ausgeführt
werden und sorgte für keine größeren zeitlichen Verluste.
Das Rendering der Bilder konnte nun auf den Fileserver erfolgen, jedoch sorgte das
Herunterladen der Texturen von allen Clients weiterhin für einen Datenstau.
4.3.3.9 Lokale Texturen
Bisher wurden alle Projektdaten wie Texturen, Caches und Szenen auf den Fileserver
kopiert und von allen Nodes benutzt.
Das Problem lag nun darin, dass sämtliche Clients, welche einen Rendervorgang
ausführen wollten, erstmals die Texturen vom Server kopierten, bevor sie ihre Daten
rendern und anschließend die gerenderten Bilder ebenfalls wieder auf den Server
kopierten. Das Volumen der Texturdaten war dabei je nach Szene unterschiedlich
und hatte eine Größe von ca. 50-200MB.
Wenn alle Rechner gleichzeitig mit dem Rendern starteten, dauerte es teilweise über
10 Minuten, bis die Texturen komplett auf alle Clients übertragen waren.
Dramatischer ist der Datenstau, wenn einige Clients Daten hochladen, während
andere neue Texturen herunterladen.
Außerdem mussten nicht nur Texturen, sondern ebenfalls Caches der Simulationen
übertragen werden, welche im Bereich von mehreren Gigabyte lagen.
Dabei kam es zusätzlich zu Abbrüchen der Datenübertragungen, wodurch Texturen
nicht übertragen wurden und im gerenderten Bild fehlten.
Die Lösung dieser Probleme bestand darin, sämtliche Daten auf jedem PC lokal zu
kopieren und diese zu verwenden. Dabei entstanden neue Probleme.
Das erste Problem war, dass sämtliche Texturpfade innerhalb der Maya-Szene auf
einen lokalen absoluten Pfad umgebogen werden mussten, was pro Szene ungefähr
100 Pfaden entsprach.
Das zweite Problem war, dass das Gesamtvolumen aller benötigten Render-Dateien
bei über 30 Gigabyte lag. Somit war es sehr ineffizient, wenn mehrere Texturen
ausgetauscht werden sollten, diese jeweils einzeln per Hand auf alle 40 Rechner zu
kopieren oder alle Rechner mit den 30 GB komplett zu überschreiben.
4.3.3.10 Pfade
Alle Pfadangaben waren bisher relativ, was die Integration auf unterschiedliche
Plattformen erleichterte. Da die Daten nun von allen Rechnern lokal genutzt werden
sollten, mussten nun sämtliche Pfade auf einen lokalen Pfad geändert werden.
Dieser Lokale Pfad musste auf allen Rechnern der Gleiche sein.
Für erste Tests wurden diese Pfade noch per Hand umgeschrieben, was diese Lösung
sehr ineffizient machte. Da sämtliche Szenen von zu Hause aus aufgebaut wurden
und somit sämtliche Pfade relativ sind, wäre es nötig gewesen, bei jedem
Szenenupdate alle 100 Pfade neu zu modifizieren, was innerhalb von Maya mit sehr
viel Zeit verbunden ist.
Für das Umbiegen der Pfade ist ein sehr nützliches MEL-Script39 auf Highend3d.com40
zu finden.
Dieses Skript analysiert sämtliche Filenodes41 innerhalb von Maya und ermöglicht
Pfadanpassungen mittels weniger Klicks.
39MEL (Maya Embedded Language)

40http://highend3d.com/maya/downloads/mel_scripts/rendering/misc/FileTextureManager-
1012.html
4.3.3.11 Synchronisation
Die nächste Herausforderung bestand darin, die Projektdaten auf allen PCs zu
verteilen und möglichst effizient zu synchronisieren. Royal Render bietet zwar die
Möglichkeit, sämtliche Texturen automatisch in einen lokalen Ordner zu kopieren,
dabei unterstützt diese Funktion keine Caches oder Plug-ins wie Realflow.
Hierfür musste eine weitere Lösung gefunden werden.
Wichtig für die Synchronisation ist der komplette Zugriff auf einen Ordner bei allen
Clients über das Netzwerk, welcher bei allen Clients der gleiche ist und über
genügend freien Datenspeicher verfügt.
Der Royal Render Server, diente dabei als mein Master. Alle PCs verfügten auf dem
Laufwerk C über genügend Speicher, weshalb ein kleines Batch Skript geschrieben
wurde, welches automatisch den Ordner „C:\RR_Data“ auf allen Rechnern anlegte.
Anschließend wurde ein weiteres Skript geschrieben, welches sämtliche Daten in
diesen Ordner kopierte.
Bei dem damaligen Datenvolumen von 11 GB dauerte es circa 13 Minuten, bis die
Daten auf 4 weiteren Rechnern kopiert waren.
Bei mehr als 4 Rechnern kam es zu Abbrüchen der Kopiervorgänge, da nun die
ersten Netzwerk-Time-outs anfingen.
Außerdem gab es ein weiteres Problem innerhalb der Netzwerkumgebung.
Da der Master auf einer Windows XP Plattform lief, war dieser automatisch auf
maximal 10 gleichzeitige Netzwerkverbindungen beschränkt, wodurch jeder 11.
Rechner, welcher auf den Master zugreifen wollte, abgeblockt wurde.
Der erste Gedanke war, die Daten erst auf den Fileserver zu kopieren und von dort
aus auf die weiteren Rechner zu verteilen. Diese Idee wurde sehr schnell verworfen,
denn nach jedem Kopiervorgang muss man überprüfen, ob wirklich alle Daten auf
allen Rechnern angekommen sind, wodurch ein zusätzlicher Kopiervorgang vom
Master auf den Fileserver eingeplant werden muss.
Also musste eine Lösung gefunden werden, welche in der Lage war, sämtliche Daten
effizient auf allen Nodes zu synchronisieren. Da die Grunddaten wie Simulation kaum
Änderungen unterlagen, ist es sehr ineffizient, existierende Daten immer wieder zu
überschreiben.
Als Lösung wurde der "Super Flexible File Synchronizer" von der Firma Super Flexible
Software gewählt.
Diese Software bietet die Möglichkeit mehrere Profile zu erzeugen, in welche genau
definiert werden kann, welche Daten wo ersetzt werden sollen. Außerdem bietet die
Software die Möglichkeit, vorhandene Daten bestehen zu lassen und ist in der Lage,
zu erkennen, wenn Daten nur verschoben wurden, sodass hier keine zusätzliche
Bandbreite benötigt werden muss.
Dabei wurden die Profile so gewählt, dass die Daten vom Masterrechner auf dem
der Royal Render Server lief, mit allen weiteren Nodes synchronisiert wurden.
Außerdem meldet die Software jede fehlgeschlagene Verbindung und fehlende
Daten, was das Überprüfen auf Vollständigkeit sehr vereinfachte.
Das Synchronisieren dauerte je nach Datenvolumen ungefähr 10 Minuten, was keine
sehr große Zeitspanne für 40 Netzwerkrechner darstellte.
41Nodes innerhalb von Maya, welche die Datenattribute wie Pfade oder Filterung
beinhalten.
Eine weitere Tatsache, die bei der Synchronisation bedacht werden musste, war der
geringe Speicherplatz des Fileserver. Der Fileserver hatte ein freies Datenvolumen von
ungefähr 350 Gigabyte, welches verwendet werden konnte.
Für die Synchronisation benötigte man eine zusätzliche Festplatte mit 1TB Kapazität.
Das Kopieren der 300GB über das interne Netz der HTW betrug etwa 11 Stunden. Um
dies zu Beschleunigen wurden im Vorfeld alle Daten komprimiert, wodurch das
Volumen auf ungefähr ¼ gesenkt werden konnte.
Der Packvorgang erfolgte durch einen Client jeweils einen Tag vorher. Die
gepackten Daten wurden auf diesen gespeichert. Diese konnten anschließend per
USB42 auf die externe Festplatte kopiert und zur weiteren Bearbeitung mit nach Hause
genommen werden.
Durch das vorherige Packen der Daten spart man ungefähr 75% der Zeit des
normalen Kopiervorgangs ein.
Das Extrahieren und Packen der Daten lief zwar im Hintergrund, benötigte von Mal zu
Mal mehr Zeit, da die Datenmenge mit der Zeit anstieg. Auch eigneten sich
gepackte Archive nicht sehr gut, wenn nur einzelne Datenblöcke benötigt wurden
oder ersetzt werden mussten. Dem entsprechend wurde noch eine weitere
Optimierungsstufe des Datentransportes eingeführt. Auf zwei zusätzlichen externen
Festplatten mit jeweils einem Terabyte Speicher wurden exakt die gleichen Daten
synchronisiert. Eine wurde an den Heim PC angeschlossen, die Zweite innerhalb des
Intranets der HTW verbunden. Die Festplatte innerhalb der HTW synchronisierte sich
alle 2 Stunden mit den Daten des Fileservers, wodurch auf dieser Festplatte immer die
aktuellen Daten lagen. Die zweite Festplatte wurde zum Bearbeiten der gerenderten
Bilder genutzt.
Der Vorteil bei diesem Verfahren war, dass man nur beide Festplatten austauschen
musste, und man nun die neuste Version sämtlicher gerenderter Daten zu Hause zum
Bearbeiten hatte, während sich die zweite Festplatte wieder mit dem Server
synchronisierte.
Der Datenaustausch bestand nun im Austausch der beiden Komponenten, was
keinen großen Zeitfaktor mehr darstellte. Nun konnte das Packen von Daten
eingespart werden.
42 USB (Universal Serial Bus)- Bussystem für serielle Datenübertragung zwischen Geräten.
4.3.4 Render Pipeline
Vereinfachte Darstellung der Renderpipeline
Abbildung 28: Render Pipeline
Die fertige Renderpipeline sah nun folgendermaßen aus:

Nachdem eine Szenerie für das Rendering fertiggestellt wird erfolgt das Kopieren
dieser Daten per FTP43 Verbindung auf den Render-Server.
Anschließend wird die Datei auf dem System per Remotedesktop44 -Zugriff geöffnet
und mittels Skript überprüft, ob alle Texturen korrekte Angaben haben bzw.
vorhanden sind.
Einzelne fehlende Texturen konnten so sehr schnell gefunden werden. Wenn alle
Pfade übereinstimmten, wurden die Pfadangaben auf den lokalen Pfad c:\rr_user
geändert.
Wenn zusätzliche Texturen zum Projekt hinzukamen, wurden diese ebenfalls per ftp
an den Renderserver geschickt. Um diese anschließend auf die einzelnen Clients zu
kopieren, kam hier der Super flexible File Synchronzier zum Einsatz. Anschließend kann
man den Rendervorgang per Plug-in, direkt aus Maya an den Royal Render Server
schicken, welcher den Renderauftrag an die zugewiesenen Nodes verteilte.
43 FTP (File Transfer Protocol), Datenübertagungsverfahren

44 Remote, engl. aus der Ferne
Diese Schritte wurden immer unternommen, bevor ein Auftrag an den Renderserver
geschickt wurde. Durch diesen Workflow wurde immer sichergestellt, dass keine
Daten fehlten und es dadurch zu keinem Fehlern kommen konnte.
Der Royal Render Server ist mit einem Feature ausgestattet, welches eine lokale
Webseite generiert, auf welcher Fortschritte und Fehler angezeigt werden können.
Da diese lokale Webseite mittels Http-Server freigegeben wurde, war es möglich,
diese von zu Hause zu erreichen.
Dadurch konnten ebenfalls sehr schnell Fehler diagnostiziert und behoben werden.
4.4 Shot Produktion
4.4.1 Einleitung
Aufgrund des Themas meiner Bachelorarbeit dreht sich der Kurzfilm natürlich
hauptsächlich um die Verwendung von Kleidungsstoffen und Flüssigkeitssimulationen.
Um dies nicht zu offensichtlich zu machen, wurden sämtliche Simulationen in den
Kontext einer kleinen Geschichte verpackt. Bevor die ersten Überlegungen zum Film
statt fanden, wurde eine Liste mit Simulationen angefertigt, welche es im Rahmen
dieser Arbeit umzusetzen galt.
Die Kunst bestand nun darin, eine möglichst zusammenhängende Kurzgeschichte zu
entwickeln, in der sämtliche Testszenarien enthalten waren. Die Ursprungsidee
bestand aus der Umsetzung der einzelnen Simulationen innerhalb einer 3D
Umgebung und einzelner Close-up Renderings. Dies wäre im Rahmen dieser Arbeit
völlig ausreichend gewesen, dennoch bestand der Wunsch, etwas Größeres zu
schaffen. Dabei sollte ein Kurzfilm geschaffen werden, der abgesehen von
Simulationen einen kleinen Unterhaltungswert bietet.
Nun will ich mir nicht anmaßen, zu behaupten, dies geschafft zu haben, dennoch
denke ich, zumindest den eigentlichen Teil der Simulationen erfolgreich gemeistert zu
haben.
Die hier aufgelisteten Verfahren stellen einen Weg dar, wie die einzelnen
Problematiken gelöst werden können. Aufgrund meines Hintergrundwissens und des
für diese Arbeit neu angeeignetem Wissens, kann ich mit gutem Gewissen
behaupten, nicht die umständlichsten Wege gewählt zu haben.
Da sich diese Arbeit natürlich hauptsächlich mit dem Gebiet der
Simulationsberechnung beschäftigt, wird nur auf diese tiefer eingegangen.
Sämtliche weitere Teilgebiete dieses Filmes werden zwar kurz erwähnt, aber nicht
genauer erläutert.
Abbildung 29: Hauptcharakter Kaki

4.4.2 Modellierung und Texturierung
Die Modellierung beschreibt das Entwickeln von 3D-Objekten. Für die Testumgebung
kamen hauptsächlich die Programme Maya und ZBrush zum Einsatz.
Für das Erstellen der einzelnen Objekttexturen sowie das des UV Layouts kamen
unterschiedliche Techniken zum Einsatz. Dabei wurden unter anderem zusätzliche
Tools wie ZBrush oder Bodypaint3D eingesetzt. Je nach Grad der Komplexität des
Objektes und nach deren Distanz zur Kamera wurden die Texturgrößen und dessen
Texturfilterung bestimmt.
Für die ersten Bildberechnungen wurden hauptsächlich TIFF Dateien verwendet,
während für das finale Rendering sämtliche Texturdaten in das Mental Ray® „.map“
Format konvertiert wurden. Teilweise wurde auf Vorlage von Referenzfotos modeliert
(Abbildung 31) (Randima Fernando, 2003).
Abbildung 30: Tisch mit Teeglas

Abbildung 31: Modellierung auf Bildbasis, links Foto, rechts 3D Model
4.4.2.1 Modellierung von Kleidung
Kleidungsstoffe werden hier als sehr einfache Objekte modelliert, welche nach einer
kurzen Simulation die nötigen Details wie Falten entwickelten, bis diese glaubhaft
waren (siehe Abbildung 32 ) .
Abbildung 32: Modellierung von Kleidung

4.4.3 Shading
In meinem Workflow folgte das grobe Shading meist nach der Texturierung. Dabei
kamen unterschiedliche Material-Shader zum Einsatz. Das finale Rendering wurde
komplett mittels Mental Ray® geführt, wodurch die Einstellungen daraufhin optimiert
wurden. Die einzelnen Shading-Netzwerke reichten dabei von Kombinationen
verschiedener Blinn Materialien (siehe Abbildung 34 und Abbildung 35), über die
typischen Mia Shader (Abbildung 33) bis hin zu SSS Shader45 (siehe Abbildung 43).
Abbildung 33: gerenderte Kamera
45 Sss (Sub Surface Scattering) Effekt, der auftritt, wenn Licht durch ein leicht
lichtdurchlässiges Objekt simuliert werden soll z. B. Haut, Milch.
Abbildung 34: Beispiel: Teil des Shadingnetzwerks für die Dose
Abbildung 35: Dose gerendert

4.4.4 Licht
Globale Beleuchtungsmodelle eigneten sich zwar wunderbar für innere Szenen, sind
aber vom Feintuning und der Kontrollierbarkeit in meinen Augen zu stark
eingeschränkt. Außerdem ist mit der Einführung von globalen Beleuchtungsmodellen
mit stark ansteigenden Renderzeiten zu rechnen, besonders wenn die
Szenenkomplexität zunimmt.
Globale Beleuchtungsverfahren dauerten somit für mich von ihrem
Berechnungsaufwand und Feintuning zu lange. (Philip Dutré, 2003)
Also wurden alle Lichter per Hand gesetzt und es kamen diverse Skripte zum Einsatz.
Die Kellerwelle konnte somit von einer Berechnungsdauer von über 2 Stunden pro
Bild auf eine Berechnungsdauer von 10-15 Minuten pro Frame auf einem Dual-Core-
System herabgesetzt werden. Damit konnte diese Szenerie komplett auf einem PC-
System ohne Hilfe einer Renderfarm berechnet werden(Peter Shirley, 2005).
Abbildung 36: Licht Setup Hof

4.4.5 Rigging
Das Rigging wurde ausschließlich innerhalb von Maya erledigt. Dabei kam unter
anderem das The Setup Machine zum Einsatz, welches die Arbeit enorm erleichterte.
So wurde für ein komplettes menschliches Rig weniger als eine Stunde benötigt. Das
Riggen der sechsbeinigen Kakerlake dagegen hat nur einen Tag benötigt. Fische
und Vögel wurden mit einfacheren Methoden entwickelt.
Abbildung 37: Erstellte Rigs

4.4.6 Animation
Die Animationen wurden hauptsächlich innerhalb von Maya umgesetzt. Dabei

wurde mit dem Trax Editor gearbeitet, welcher das Blenden von Posen, Expression
oder Caches zulässt. Für die Verarbeitung von Motion-Capture-Daten kam
insbesondere Motionbuilder zum Einsatz. Um die Final zu rendernde Szene so sauber
wie möglich zu halten, wurden sämtliche Animationsdaten gecacht. Die finale
Szenerie bestand dann nur noch aus der Geometrie, welche von diesem Cache
gesteuert wurde. Bei der Animation der Kakerlake wurden diverse Standardposen
sowie verschiedene Loops46 generiert. Diese wurde dann als Vorlage für die
einzelnen Sequenzen genutzt(Wells, 2007).
Abbildung 38: Walkcycle der Kakerlake in Keys
46 Sich wiederholende Animationen wie Walkcycle

4.4.7 Simulationen
4.4.7.1 Szene 1 - Der Marktplatz
Der Marktplatz gehörte mit 7 gleichzeitigen Simulationen mit zur aufwendigsten

Szenerie des Filmes. Hierbei wurde nicht nur versucht ein möglichst weiträumiges
Terrain zu modellieren, sondern ebenso einen möglichst dynamischen Look zu
kreieren, indem mehrere Simulationssysteme zur Verwendung kamen.
Als Erstes musste ein Ozean generiert werden, welcher möglichst realistisch wirkt und
unter anderem mit dem Balken vom Steg interagieren konnte. Für die Erstellung der
Meeresoberfläche wurde der in Maya integrierte Ozean-Shader verwendet, welcher
mit einer Nurbs Fläche gekoppelt wurde. (Balázs, Ákos., 2008)
Die Auflösung der Nurbs Fläche und die einzelnen Shader-Einstellungen wurden
anschließend an die der Szenerie angepasst. Zusätzlich wurde ein 3D- Fluid-Container
verwendet, um einen leichten Nebel über dem Wasser zu simulieren. Der Standard-
Ozean-Shader von Maya liefert dabei schnell relativ brauchbare Ergebnisse, welche
für mein Vorhaben völlig ausreichten. Um die wellenförmige Bewegung auf weitere
Objekte wie Boote zu übertragen, wurde ein Locator47 an die Wasseroberfläche
gebunden, von dem aus die Transformations- und Rotationswerte auf die
schwimmenden Objekte übertragen wurden.
47Lokator oder auch NULL Objekte können über Objekteigenschaften wie Position, Rotation,
Skalierung verfügen, aber beinhalten keine Geometrie.
4.4.7.2 Fahne Am Mast
Die Fahne wurde innerhalb von Maya mittels Nucleus Solver berechnet. Der
Hauptwind wurde dabei vom Solver gesteuert und musste bei sämtlichen
Hafensimulationen denselben Werten entsprechen. Dadurch wurde ein
gleichmäßiges Windgefühl vermittelt. Die Solver-basierten Einstellungen für Wind und
dessen Unregelmäßigkeiten innerhalb von Maya folgen natürlich keinem richtigen
Zufallsgenerator, wodurch das Zufallsmuster des Windes optisch immer zu sehr nach
CG aussieht. Dies gilt es, innerhalb von CG-Filmen zu vermeiden. Für realistischeres
Verhalten der Fahne kamen also zusätzlich Partikel zum Einsatz, welche mit einer
hohen Geschwindigkeit auf die Fahne geschossen wurden und nur eine geringe
Masse hatten. Dadurch konnten weitere kleinere Details erzeugt werden, die einen
wesentlich zufällig wirkenden Look erzeugten.
Die Simulation wurde anschließend als Cachefile abgespeichert. Nachdem dieser
Vorgang abgeschlossen war, konnten sämtliche Simulations-Nodes wie
Gravitationsfelder oder Solver gelöscht werden. Alle Animationen waren nun
gecacht. Die Idee der Kameradrehung innerhalb der ersten aufprallenden Welle
ging von Herrn Bremer aus, welche daraufhin adaptierte wurde. Das Problem, was
dadurch erzeugt wurde, war, dass die Fahne im Hintergrund nun 200 Frames länger
zu sehen war und dadurch das generierte Cachefile von seiner Länge nun nicht
mehr ausreichte. Die zeitlich effiziente Lösung war es den Cache per Maya Trax
zweimal zu importieren und beide Caches clever zu überblenden. Das generieren
eines neuen Caches hätte wesentlich länger gedauert.
Abbildung 39: Flyer und Fahne

4.4.7.3 Flyer am Stein
Als Solver(siehe Solver) kam der Gleiche, wie für die Fahne zum Einsatz. Der nächste
Schritt bestand darin, die ungefähre Flugbahn des Flyers zu bestimmen. Dafür kamen
Turbulenz und Vortex-Fields zum Einsatz. Um mehr Kontrolle über das Abfliegen des
Flyers vom Stein und vor allem eine einfachere Simulationssteuerung zu haben,
wurde ein weiterer Kontroller entwickelt (siehe Abbildung 40).
Dabei stellt der Kasten rechts im Bild einen Schieberegler dar. Wenn der gelbe Balken
unterhalb der roten Linie gezogen wurde, so fing das Blatt an, sich vom Stein zu
lösen.
Somit hat man eine ziemlich genaue visuelle Darstellung der Animation und es
mussten insgesamt nur zwei Keys gesetzt werden. Der gebaute Regler nimmt per
Expression hauptsächlich Einfluss auf die Stickyness48 Parameter der einzelnen
Objekte.
Abbildung 40: Flyer am Stein
48 Stärke der Haftung von Objekten aneinander

4.4.7.4 Welle auf der Promenade
Für die Erstellung eines Spritzers mit dieser Auflösung kam eine externe Lösung zum
Einsatz, um eine möglichst große Kontrolle auf die Simulation und die spätere Mesh-
Generierung zu haben. Das Besondere bei Wellenspritzern ist, dass diese unter
anderem zur Schaumbildung führen, wodurch diese Simulation als etwas Spezielles
eingestuft wird. Das erfordert Spezialwissen bezüglich der Partikelsimulationen.
Als externe Lösung hierfür wurde RealFlow gewählt, da dieses Programm zu den
ausgereifteren auf Partikel-basierenden Flüssigkeitssystemen gehört.
Es wurden einfache geometrische Proxys innerhalb von Maya entwickelt und diese
inklusive der Kamerafahrt nach RealFlow exportiert.
Anschließend wurde nach existierenden RealFlow-Skripten, welche der
Schaumgeneration dienten gesucht. Nach einigen Tests stellte sich das
"WavesFoamSpray" Skript als einfach zu handelndes Skript heraus. Auf Basis dieses
Skripts wurde ein eigenes Schaum-Skript aufgebaut, welches anschließend auf für die
Simulation verwendet wurde.
Abbildung 41: Wellensimulation mit Schaum

4.4.7.5 Stop Motion Simulation
Eine Tatsache, die man sich bei einem sehr kurzen Planungszeitraum vor Augen
führen muss, ist, dass man ständig neuen Einflüssen unterlegen ist, welche einen dazu
zwingen, aktuell geplante Dinge ändern zu müssen. Als sämtliche Anfangssimu-
lationen abgeschlossen waren, fand ein weiteres Treffen mit Professor Bremer statt,
bei dem der aktuelle Standpunkt vor Augen geführt wurde. Nachdem er die erste
Kamerafahrt gesehen hatte, kam die Idee, ob man die Kamera Stop-Motion ähnlich
um die Welle herumdrehen könne. Dadurch entstand eine neue Kette von
Aufgaben. Zum einem musste es möglich sein, sämtliche Simulationen innerhalb von
Maya gleichzeitig anhalten bzw. zeitlich beeinflussen zu können. Sämtliche
Simulationen bauten auf einem framegenauen Cachesystem auf. Dieses System ist
normalerweise mit dem internen Timer von Maya gekoppelt. Um dies umgehen zu
können, muss ein zusätzliches Attribut entworfen werden, welches einen neuen
Zeitablauf innerhalb von Maya darstellte. Anschließend wird dieses Attribut in
einzelnen Nodes der Caches verknüpft, so dass diese nun nicht mehr auf den
integrierten Maya-Timer reagieren, sondern den neuen Timer verwenden. Dies verlief
problemlos mit sämtlichen Kleidungsstoffen, wobei die Simulation der Felswelle etwas
mehr Zeit benötigte.
Die Welle wurde mit einer Auflösung berechnet, welche nicht für diese nahe und
detaillierte Aufnahme gedacht war. Außerdem ist der Prozess eines realistisch
wirkenden Shadings um einiges aufwendiger, wenn die Kamera sehr nahe an
volumetrische Objekte wie Schaum kommt, da dieser dann einen volumetrischen
Körper darstellt, während er von weiter weg, als simpler Körper berechnet werden
kann.
4.4.7.6 Hintergrundcharaktere
Cloth Simulation der Hintergrundcharaktere:

Für die Animation und Simulation der Hintergrundcharaktere wurde ein Mensch
designt, der typische orientalische Kleidung trug.
Dazu gehörten unter anderem eine etwas längere Robe und ein Kopftuch. Dies ist
die einzige Animation, bei der Mocap49 Daten verwendet wurden. Dabei kam
Motionbuilder zum Einsatz, welches verwendet wird, um die einzelnen Aufnahmen
bearbeiten zu können. So wurden längere Bewegungsabläufe kreiert.
Dabei wurden 3 Grundtypen von Menschen erstellt.
- Stehend
- Beobachtend
- Umhergehend
Für die Kleidungsstoffsimulation verwendete man erneut den in Maya integrierten

Nucleus Solver. Damit berechnet man als Erstes die längere Robe und anschließend
das Kopftuch. Grund für diese Vorgehensweise war, dass sich die Kollision von dem
Kopftuch nach der Robe richtet, die Robe aber kaum vom Kopftuch beeinflusst wird.
Um der Robe ein realistischeres Verhalten zu geben, wurden individuelle
Weightmaps50 für deren Stickyness und Damping sowie Stretching Parameter
gezeichnet. Weiterhin kamen mehrere Point Constraints zum Einsatz, um das
Verrutschen der Kleidung über einen längeren Zeitraum zu unterbinden.
Der zum Kopftuch gehörende Ring konnte nicht gecacht und später auch nicht an
die Caches gebunden werden. Um den Kopftuchring mit dem Kopftuch mit
wandern zu lassen, kam ein Wrap Deformer51 zu Einsatz, welcher den Ring etwas
verbiegt, was aber aufgrund der hohen Distanz zur Kamera kaum auffällt.
Abbildung 42: Hintergrundcharaktere
49 Kurzform für Motioncapture, ist ein Verfahren zur Übertragung von Positionsdaten auf
Computersysteme.
50 Map mit der die einzelnen Attribute gewichtet werden können.
51 Wrap Deformer auch bekannt als Surface Deformer, versuchen die Punkte eines Objektes
auf ein anderes abzubilden.

4.4.7.7 Frau mit Kamera
Für die Cloth Simulation des Mädchens wurde das Top per Point Constraints(siehe
Seite 15) an den Oberkörper gebunden und die Simulation anschließend berechnet.
Während alle Kollisionen bisher mit sehr niedrig aufgelösten Meshes erfolgten, wurde
hier ein Objekt mit 35 000 Polygonen als Kollisionsobjekt verwendet. Die Simulation
verlief trotzdem sehr stabil und dauerte nur wenige Minuten.
Abbildung 43: Frau mit Kamera

4.4.7.8 Reißende Ringe
Dieses Szenario beinhaltet Stoffe, welche reißen können. Innerhalb von Maya und
vielen anderen Systemen besteht die Möglichkeit, sogenannte Tearable Surface
(siehe Cloth Constraints) zu definieren. Dabei werden einzelne Punkte ausgewählt
und mit einer Glue Strenght52 versehen. Innerhalb von Maya wird während der
Simulation bei jedem Schritt geprüft, wie hoch die Kräfte zwischen den Punkten mit
welchen Vektoren anliegen. Nun kann ein Maximum definiert werden, welches
innerhalb des Meshes für die einzelnen Punkte existiert. Wenn das Maximum
überschritten wird, trennt der Punkt die Verbindungen zu seinen benachbarten
Punkten und das Mesh beginnt zu reißen.
Genau dieses Verfahren kam bei den Ringen zum Einsatz. Da die Anwendung von
reißenden Stoffen standardmäßig auf dünne Stoffe ausgelegt ist, musste hier etwas
mehr an den Parametern gestellt werden, bis wirklich der Eindruck entstand, dass es
sich hierbei um ein dickeres Gummiband handelt.
Abbildung 44: Reißende Ringe
52 Glue Strenght, engt. Stärke des Zusammenhalts

4.4.7.9 Blumen gießen
Die Fluid Simulation des Blumengießens ist die Einzige, welche ausschließlich mit
Maya-Partikeln und des Nucleus Solver innerhalb von Maya erstellt wurde. Grund
dafür war die relativ niedrige Auflösung, die für das Objekt benötigt wurde und die
Tatsache, dass sich integrierte Lösungen besser mit Skripten kombinieren lassen. Für
die einzelnen Wasserstreifen wurde eine Emitter-Textur verwendet, die genau
definierte, wie stark die Partikeldichte sich an welchen Stellen verhalten soll.
Weiterhin wurde die Fluid Simulation möglichst dynamisch und flexibel gestaltet.
So musste z. B. für die gesamte Animation der Flüssigkeit kein einziger Key gesetzt
werden. Per Expression Skript wurde die Simulation so gesteuert, dass die Gießkanne
anfängt, zu gießen, wenn ihre Rotation einen gewissen Winkel übersteigt. Damit
verhielt sich die Gießkanne wie ein gefüllter Körper.
Die beginnende Partikelemittierung wurde ebenfalls durch eine Ramp53 gesteuert,
welche die Wirkung hatte, dass die Partikel zu Beginn nicht gleichmäßig aus der
Kanne kommen, sondern von unten anfangen. Bei der späteren Animation der
Kannenbewegung muss man sich keine weiteren Gedanken um das Fluid System
machen, da es völlig dynamisch reagiert. Für das finale Rendering wurden dabei
zwei Renderlayer verwendet, einer für die reine Partikelsimulation und ein weiterer,
welcher mittels NParticles das Objekt der Flüssigkeit bildete. Auch mussten beide
Simulationen für ein verteiltes Rendering gecacht werden.
Maya bietet zwar die Möglichkeit einen Partikel-Cache zu generieren, jedoch lässt
Maya es nicht zu, einen absoluten Pfad zu diesem Cache zu definieren.
53 Verlauf von Werten entlang eines Koordinatensystems

Es gibt jedoch den Trick innerhalb der Maya Projektpfade, den Pfad aller Caches auf
einen absoluten Pfad zu legen. Das Verfahren lässt nur einen absoluten Pfad zu. Mit
dieser Methode ist es also nicht möglich, Caches auf unterschiedliche Laufwerke zu
verteilen. Um das bewerkstelligen zu können, kann man allerdings den Cache mittels
Realflow Plug-in in eine SD Particle Cache54 Sequenz exportieren, welche absolute
Pfade zulässt. So war der anfängliche Ablauf aufgebaut.
Abbildung 45: Blumen gießen.
54 Ein RealFlow Cache

4.4.7.10 Wolken
Die Wolken innerhalb der Szene wurden mit 3D-Fluid-Containern umgesetzt.

Dabei kamen zwei 3D- Fluid Container zum Einsatz, welche jeweils dickere Wolken
und eine Nebelschicht erzeugten.
Da dieser Prozess zu aufwendig ist, wurden die Wolken in den meisten Szenen
einfach während der Komposition gelöst. Das Zeitintensive bei Fluidcontainern
innerhalb von Maya liegt an der schlechten Visualisierungsmöglichkeit der
Simulation. Es gibt also keine gute Vorschaumöglichkeit innerhalb von Maya, außer
dem Rendern der Sequenz. Andere Systeme wie FumeFX bieten dagegen ein kleines
Preview-Fenster, indem man ein ziemlich genaues Gefühl über die finale Berechnung
erlangen kann.
Abbildung 46: Generierte Wolken

4.4.8 Szene 2 – Seitengasse
In dieser Szenerie ging es hauptsächlich darum, einen Übergangsbereich zwischen

den einzelnen Filmabschnitten zu finden und eine Softbody-Simulation dabei
unterzubringen. Da sich wie bereits beschrieben, Softbodys inzwischen mit NCloth-
Objekten umsetzen lassen, wurde dieses neue Feature innerhalb von Maya auf die
Probe gestellt. Früher war das Erstellen von Softbodys innerhalb von Maya mit
wesentlich mehr Handarbeit verbunden, da es notwendig war, erst einen Softbody-
Proxy mit Partikeln zu erstellen, bei dem das Volumen durch Springs gesichert werden
musste. Neuere Systeme nehmen einem diese Arbeit ab und konfrontieren einen nur
noch mit den nötigen Parametern. Es handelte sich hierbei wahrscheinlich um die
einfachste Simulation innerhalb des gesamten Films, bei der nur zwei Felder
verwendet werden.
Abbildung 47: Seitengasse

4.4.9 Szene 3 – Hof Gelände
4.4.9.1 Kleiner Brunnen
Die Herausforderung an dieses System bestand darin, eine geeignete Lösung zu

finden, eine kleinere durchgehende Fluidsimulation zu schaffen, welche einem
typischen Brunnen entsprach.
Dabei kam Realflow zum Einsatz. Innerhalb der Szenerie waren besonders die
einzelnen physikalischen Objekteigenschaften wichtig, sowie deren
Skalierungsfaktoren. Die Szenerie wurde mit sehr wenigen dynamischen Feldern
(siehe Dynamische Felder) erstellt.
Abbildung 48: Kleiner Brunnen

4.4.9.2 Großer Brunnen
Die Berechnung eines Brunnens war mit dem kleinen Brunnen bereits abgeschlossen.
Bisher kamen Partikel zwar in jeglicher Art von Flüssigkeitssimulationen vor, aber noch
nicht für typisches Schwarmverhalten. Die Fische innerhalb des Brunnens simulieren
somit ein intelligentes Schwarmsystem. Dabei handeln die Fische nach den
einfachen Regeln, dass sie gerne etwas im Kreis schwimmen, ab und zu an die
Oberfläche kommen und sich gegenseitig und vor allem den Brunnenwänden
ausweichen. Dieses Verhalten konnte durch die Kombination mehrerer Felder
innerhalb einer Partikelsimulation bewirkt werden. Es kamen sieben Felder mit
unterschiedlichen Aufgaben zum Einsatz(siehe Abbildung 49). Nachdem die
Partikelsimulation abgeschlossen war, wurde jeder Partikel anschließend mit einem
animierten 3D-Fischmodell ausgetauscht. Durch den Bewegungsvektor der einzelnen
Partikel konnte außerdem die Rotation bestimmt werden, welche an die einzelnen
Fischmodelle weitergereicht werden konnte, damit diese korrekt in Schwimmrichtung
rotieren. Das System verlief randomisiert und es war nicht möglich, die Simulation
ohne überschüssige Nodes in die Hauptszenerie importieren zu können. Es ist
innerhalb von Maya zwar möglich, Instanzen von Objekten auf Koordinaten der
Partikeln zu erzeugen, aber es ist nicht möglich, die Bewegungsdaten komplett
unabhängig auf die Modelle zu übertragen.
Doch auch für solche Aufgaben gibt es eine Lösung.
Um genau dies zu bewirken, wurde das „Uninstancer Mel Script for Maya“ von
Highend3d verwendet. Anschließend wurde nur noch die reine Fischgeometrie mit
deren einzelnen Keyframes verwendet und es konnte das Partikelsystem und deren
Felder gelöscht werden. Somit hatte hat man wieder einen sauberen Szenenaufbau.
Für die Wasseroberfläche kam ein Ozean Shader zum Einsatz, welcher in Verbindung
mit einem dielectric photonic material55, ein korrektes kaustisches Verhalten zeigte.
Abbildung 49: Fische im Brunnen
55 Material zur Berechnung von kaustischen Photonen

4.4.9.3 Teeglas
Nach den bisherigen Simulationen wird man vermutlich denken, dass die Simulation
eines einfachen Teeglases, welches umkippt, sehr leicht zu realisieren sei.
Durch vorherige Recherche wurde herausgefunden, dass es sehr problematisch ist,
wenn sich Flüssigkeitspartikel sehr schnell über eine größere Distanz bewegen.
Aufgrund des Größenunterschieds von dem kleinen Teeglas und deren weiten Weg,
den die Partikel zurücklegten, bestätigte sich hier die Vermutung.
Für die Umsetzung der Szenerie wurde Realflow verwendet. Die Berechnung der
Partikel war sehr zeitaufwendig. Das Problem war, dass die Distanz der einzelnen
Partikel zu groß ist und Realflow aufgrund dieser abstürzte. Die Lösung bestand
letztendlich darin, dass eine sehr hohe Partikeldichte (Auflösung) zum Einsatz kam
und die Szene komplett geschrumpft wurde.
Eine Flüssigkeit, die verkleinert wurde, verhält sich logischerweise anders als die
gleiche Flüssigkeit auf einer wesentlich größeren Skalierung. Also mussten sämtliche
Werte wie Luftdruck, Gravitation und Masse, so angepasst werden, dass sich die
Flüssigkeit auf dem kleinen Raum genauso wie eine größere Menge verhält.
Weiterhin wurden Partikel, welche sich auf den Tisch befanden und nicht mehr
innerhalb des Blickwinkels lagen, sofort aus der Simulation entfernt. Durch die
Kombination dieser beiden Tricks war es erst möglich, die Teeglas-Simulation ohne
Abbrüche zu berechnen.
Abbildung 50: Tee

4.4.10 Szene 4 – Die Dose
Bei der Betrachtung sämtlicher im Film vorkommender Simulationen fehlte bisher die
einfachste und älteste. Die Rigid Body Simulation (siehe 2.2) bezieht sich nur auf feste
Körper, welche miteinander kollidieren. Um diese Simulation innerhalb von Maya
korrekt erscheinen zu lassen, mussten mehrere Dinge beachtet werden. Die
Gesamtszenerie war in einem Maßstab entwickelt, welcher unserer Welt ziemlich
genau entsprach. Die Dose innerhalb der Szenerie war dabei nicht sonderlich groß.
Die einzelnen Objekte innerhalb der Dose waren dementsprechend im Verhältnis zur
Welt extrem klein. Es ist zwar möglich, innerhalb von Maya die
Berechnungsabschnitte sehr genau einzustellen und deren Kollisionsabstände,
jedoch sind Simulationen innerhalb von Maya mit einer solch geringen Skalierung
sehr fehleranfällig. So kam es trotz eines sehr geringen Stepsizes56 mit vielen
Iterationen57 und einer geringen Kollisionsdistanz während der Simulation zu
Interpenetrationen58 und falschen Kollisionserkennungen. Weiterhin war die gesamte
Berechnungsdauer stark angestiegen und dauerte nun ungefähr 10 Minuten,
während die Simulation vorher nahezu in Echtzeit ablaufen konnte.
Die Lösung für dieses Problem bestand darin, dass sämtliche Objekte innerhalb der
Dose so skaliert wurden, dass die Größe der Objekte in etwa dem, der Realität
entsprach. Außerdem wurden erneut Proxys aller Objekte verwendet. Somit verlief
die Kollisionserkennung wieder fehlerfrei und die Berechnungsgenauigkeit konnte
verringert werden, was sich in der Simulationsgeschwindigkeit positiv bemerkbar
machte.
56 Größe der Abschnittsberechnungen

57 Anzahl der Durchgänge eines Algorithmus
58 Ineinander gehen von Objekten.
Abbildung 51: Rigid Body Simulation

4.4.10.1 Die Korridorwelle
Die Simulation der Welle stellte eine besondere Herausforderung dar. Sie ist als
Höhepunkt der Simulationstests gedacht und spiegelte dies mit einer
Berechnungsdauer von ca. 600 Stunden wieder.
Diese Simulation wurde als Erstes begonnen, während man noch in der groben
Planung steckte. Es war also bereits vorher klar, dass es eine Korridorwellen-Simulation
innerhalb des Kurzfilms geben musste. Das Setup der Szenerie wurde innerhalb
weniger Stunden in Maya vorbereitet, indem der Gang und einige Objekte
modelliert wurden. Ursprünglich befanden sich noch einige Stühle in diesem Gang,
welche ebenfalls von der Welle erfasst wurden.
Die Ursprungsidee war eine Welle, welche einen typischen Bürogang fluten sollte, in
welchem sich Stühle und ein Getränkeautomat befinden. Dazu wurden einfachere
Proxys für alle Elemente, welche mit den Partikeln interagieren sollten modelliert.
Anschließend wurde die Interaktion der Partikel mit jedem beweglichen Objekt
getestet und deren Parameter angepasst, bis sie sich glaubwürdig verhielten.
Nachdem das Testgelände von Professor Bremer verwendet wurde und feststand,
einen zusammenhängenden Film zu produzieren, war die anfängliche Befürchtung,
diese Simulation vielleicht nicht verwenden zu können. Denn das Gelände stellte
eine sehr altertümliche Umgebung dar, zu der ein Gang mit Stühlen überhaupt nicht
passte.
Nach genauerer Betrachtung der Szenerie, wurde der Büroflur in einen Kellergang
umgewandelt, welcher zum restlichen Gelände passte.
Ein Problem das weiterhin Bestand hatte, war die Tatsache, dass die Bürostühle und
der Getränkeautomat ebenfalls nicht in einen Keller passen.
Die Stühle befinden sich weiter hinten im Gang, wodurch die aktive Kamera etwas
weiter nach vorne verschoben wurde. Es mussten die Bodenbretter mit den bereits
berechneten Kollisionen von den Stuhlbeinen angepasst werden, damit die
Simulation weiterhin realistisch wirkte.
Der Getränkeautomat wurde durch eine Kiste ersetzt, welche exakt der gleichen
Größe und etwa der gleichen Masse entsprach.
Nachdem man nun wusste, wo sich die Kamera befinden würde, konnte das
passende Mesh mithilfe der berechneten Partikel generiert werden.
Nach 60 Stunden Berechnungsdauer betrug die Partikelanzahl über eine Million.

Abbildung 52: Berechnungsverlauf der Kellerwelle innerhalb der ersten 30 Stunden

Abbildung 53: Simulation nach 40 Stunden
Abbildung 54: Frame 297 nach 60h Berechnung
Abbildung 55: Frame 309 nach 100 Stunden

4.5 Komposition
4.5.1 Renderpässe und Renderlayer
Jede Szene wurde mit verschiedenen Pässen und Layern gerendert, welche später
im Compositing zusammengesetzt wurden. Das Erstellen der einzelnen Pässe wurde
durch den Mental Ray® Framebuffer realisiert, welcher in Maya 2009 über die
Einstellungen der Renderpässe steuerbar ist.
Zusätzliche Ebenen wurden mittels Renderlayer generiert. Sie bestanden
hauptsächlich aus Objekt-ID-Pässen oder Transparenz-Matten, welche für das
spätere Compositing dienten.
Nach den ersten gerenderten Bildern mit Realflowdaten wurde festgestellt, dass
diese sehr unterschiedlich von den einzelnen Nodes berechnet wurden und oftmals
schwarze Renderblöcke enthielten, welche die Endergebnisse unbrauchbar
machten. Darum wurden sämtliche dynamische Prozesse einzeln gerendert und
während des Compositing kombiniert (Brinkmann, 1999).
4.5.2 Tiefenschärfe
Die Tiefenunschärfe wurde komplett im Compositing umgesetzt. Für die Berechnung

einer korrekten Tiefenschärfe war eine Tiefenmaske von Voraussetzung. Diese konnte,
wie schon beschrieben, aus dem Framebuffer59 generiert werden.
Da anfangs noch nichts Genaues über deren Ergebnisse vorhergesagt werden kann,
wird mit diversen Lösungen experimentiert.
So wurde z. B. ein Shading Netzwerk aufgebaut, welches die Darstellung der Tiefe in
Echtzeit innerhalb von Maya ermöglichte und bei dem sich der Punkt der
Tiefengenerierung verschieben lässt.
Da dieser Prozess für jede Szene zu zeitintensiv war, wurden später nur zwei
Renderpässe mit jeweils einer Kamera Depth Map60 und einer weiteren Depth Map
generiert, welche genau ausgemessen wurden.
Eine war für die globale Tiefe und beinhaltete eine ziemlich weite Distanz, während
die 2. für Close-up-Aufnahmen sehr viele Abstufungen zur Kamera nahegelegenen
Objekten zeigte. (Park, 2004)
59 Zwischenspeicher, welcher sämtliche Informationen der zu berechnenden Bilder beinhaltet.

60 Tiefenmaske
4.5.3 Bewegungsunschärfe
Die Bewegungsunschärfe wurde ebenfalls während der Komposition gelöst. Um

nachträglich eine Bewegungsunschärfe auf ein Objekt zu legen, sind mehrere Wege
verbreitet.
Je schneller sich ein Objekt in eine gewisse Richtung bewegt, umso höher wird seine
Unschärfe. Bei Filmkameras spielt außerdem die Belichtungszeit eine große Rolle.
Besonders bei CG61-Grafiken spielt Bewegungsunschärfe eine bedeutende Rolle, um
einer Animation das Gefühl von Realismus zu geben.
Die Bewegungsunschärfe kann zwar innerhalb der 3D-Umgebung berechnet
werden, dies bietet aber gleich mehrere Nachteile. Zum einem kann die
Bewegungsunschärfe je nach genutzten Renderer sehr zeitintensiv sein und zum
anderen verliert man etwas Kontrolle über die Gesamtanimation, wenn die
Unschärfe in den Bildern integriert ist.
So muss man sich vorher genau darauf festlegen, welche Belichtungszeit und wie
viele Samples die Unschärfe haben soll.
Um flexibel und schnell in der Berechnung zu bleiben, wird die Bewegungsunschärfe
erst im Compositing erzeugt.
Dafür gibt es folgende Möglichkeiten:
Manuell: Es ist möglich dies per Hand zu erzeugen, indem man eine
animierte Maske zeichnet und einen geeigneten
Unschärfefilter mit der Bewegung anlegt.
Motion Tracking: Die 2. Methode ist, die Pixel des Bildes auf Veränderungen
zu analysieren und daraus den Bewegungsvektor zu
schlussfolgern. Nachdem der Bewegungsvektor ermittelt
wurde, kann bestimmt werden, wie stark und in welche
Richtung die Unschärfe angewendet werden soll. Die Pixel
können dabei nach verschiedenen Kriterien überprüft
werden, was bei starken Kontrasten sehr gut funktioniert.
Bei weniger kontrastreichen Farbwerten führt dies oftmals
zu Fehlern. Diese Form der Bewegungsunschärfe
funktioniert also gut bei einzelnen Objekten, führt aber
oftmals zu Fehlern bei mehreren bewegten Objekten und
deren Überlappungen sowie Kamerabewegungen, in
welchen bewegte Objekte vorkommen.
61 CG Kurzform für Computer generiert

Motion Vektor: Das 3. und in meinen Augen beste Verfahren ist, die
Bewegungsvektoren beim Rendering zu erstellen. Dabei
kann der Bewegungsvektor anhand der Pixelfarbintensität
und der Farbe bestimmt werden. Die meisten
Anwendungen akzeptieren dabei ein Bildformat, in dem
geringe Bewegungen durch eine grünliche und stärkere
Bewegung durch eine rötlichere Farbe gekennzeichnet
werden. Zur Erstellung der Bewegungsvektoren gibt es
mehrere Möglichkeiten, wobei die Entscheidung auf die in
Maya versteckten Mental Ray® Productionsshader
gefallen ist. Diese sind relativ schnell umzusetzen und
benötigen keine zusätzliche Software, da sie zwar von
Mental Ray®, aber noch nicht offiziell von Maya
unterstützt werden.
4.5.3.1 Integration der Productionsshader in Maya
Shader, die offiziell nicht unterstützt werden, können nicht über die Maya Oberfläche
gefunden werden. Daher wird ein kurzes Mel-Script für die Erstellung des
Shadernodes benötigt:
mrCreateCustomNode -asTexture "" mip_motion_vector;
Nach der Ausführung des Skriptes erscheint folgender Node im Hypershade
Abbildung 56: mip_motion_vector Node in Maya
Die Output Message des Nodes kann nun mit dem Camerashape wie folgt
verbunden werden. Die Attribute sind ebenfalls versteckt und müssen erst in den
Display Settings aktiviert werden.
Abbildung 57: Connection Editor

Innerhalb des Camerashape-Nodes wird nun der „mip_motion_vector“-Node als

"Legacy Output Shader" angezeigt. Hier können nun die für den Shader zur
Verfügung gestellten Daten wie Depth, Color und Motion Vector aktiviert werden,
was anschließend zum gewünschten Ergebnis führt (mental ray, 2007).
Abbildung 58: Legacy Output Shader

4.5.4 Kombination der einzelnen Kanäle
Beauty Pass (bestehend aus weiteren Ebenen)
Abbildung 59: Beauty Layer
+ Ambient Occlusion
Abbildung 60: Ambient Occlusion Layer
+ Masken
Abbildung 61: Masken Layer

+ Motion Vector
Abbildung 62: Motion Vector Layer
+ Depth Pass
Abbildung 63: Depth Layer
+ Diverse Filter (Farbkorrekturen, Filter etc.)
||
Abbildung 64: finales Compositing

4.6 Steine auf dem Weg der Produktion
Die folgenden Fälle beschreiben Fehler, welche während meiner Arbeit aufgetreten
sind und mit eingeplant wurden.
4.6.1 Servercrash
Die Rechner innerhalb der Labore befanden sich keineswegs in einer geeigneten
Umgebung für dauerstrapazierte PCs. Denn es gab weder extra Kühlsysteme, USV62
sowie erweiterte Sicherungsmechanismen. So kam es des Öfteren vor, dass sich
einzelne Laborrechner abstürzten und nicht mehr erreichbar waren.
Abstürze der einzelnen Rendernodes waren nicht sehr problematisch, da diese
einfach neu gestartet werden konnten.
Es geschah einige Male mit dem Labor-PC-Ananake1, auf dem die
Serveranwendung lief. Dabei war es nicht selten, dass die Datenbank fehlerhaft war
und sämtliche Einträge wie Renderjobs verloren gingen. Außerdem musste bei
Abstürzen oftmals zum Gelände der HTW gefahren werden und die abgestürzten
Rechner neugestartet und auf eventuelle Ursachen überprüft werden.
4.6.2 Rendercrashes
Die Szenen wurden innerhalb einer Dualcore-64-Bit-Plattform erstellt, welche über vier
Gigabyte RAM63 verfügte.
Nachdem die Erste ins Rendering geschickt wurde, wurde festgestellt, dass kein
einziger PC im Labor in der Lage war, diese zu rendern. Nach Logfileanalyse stellte
sich heraus, dass Mental Ray® nicht genügend Arbeitsspeicher hatte und deshalb
abbrach. Selbst nach mehreren Speicherverbesserungen innerhalb der Szene, wie
das Umwandeln aller Texturen in ein für Mental Ray® besser geeignetes Format und
manuelle Angaben von Ressourcennutzung, brach der Rendervorgang auf den
Labor-PCs ab.
Mich verwunderte, dass der Rendervorgang schon bei 60% Auslastung des
Arbeitsspeichers abbrach.
Auf einem 64-Bit-Dualcore-System konnten die Szenen problemlos gerendert werden.
Der eingegangene Kompromiss war, den BSP64 innerhalb von Maya stark zu erhöhen
und teilweise sogar auf Large-BSP65 zu wechseln.
Dadurch wurde das Rendering erst möglich gemacht, aber es dauerte dafür etwas
länger.
62 Unterbrechungsfreie Stromversorgung
63 RAM – Random Access Memory auch bekannt als Arbeitsspeicher
64 BSP (Binary Space Partitioning) dient zur beschleunigten Berechnung von Raytracing, dabei
können die BSP-Größe und deren Unterteilungsblöcke großen Einfluss auf die Renderzeiten
und der zu verbrauchenden Ressourcen nehmen.
65 Sehr großer BSP, was zu ungefähr 15% längerem Renderzeiten führt.
4.6.3 Fehler während des Rendervorgangs
4.6.3.1 Kaustische Photonenberechnungen
Photonenberechnungsfehler innerhalb von Sequenzen. Sie traten relativ selten und

während meiner Arbeit nur im Zusammenhang mit den Ozean Shader auf.
Abbildung 65: Photonenberechnungsfehler (links), korrekt (rechts)
4.6.3.2 Cachedaten
Probleme mit Cachedaten sind schwer zu finden, da jedes Bild einzeln

durchgesehen werden muss. Diese Form von Fehler trat sehr zufällig auf und konnte
in keiner Weise vorhergesagt werden. Frames mussten mehrere Male gerendert
werden.
Abbildung 66: Cachingfehler (links), korrekt (rechts)

4.6.3.3 Fehlerhafte Blöcke
Fehlerhafte Blöcke traten je nach Szene zwischen 5-10 % bei den berechneten
Bildern auf, wodurch sie neu gerendert werden mussten. Sie konnten allerdings leicht
ausfindig gemacht werden, da hier das gerenderte Bild direkt geschädigt war.
Ursache:
ständiger Ausfall von Netzwerkverbindungen innerhalb der Farm,
wodurch es zu Schreib- und Lesefehlern kam.
Abbildung 67: Blockfehler (links), korrekt (rechts)
4.6.3.4 Shadingfehler
Shadingfehler traten zwar nicht sehr häufig auf, waren jedoch schwer zu finden. Die
Fehler konnten durch neues Rendern behoben werden.
Abbildung 68: Shadingfehler (links), korrekt (rechts)

4.6.4 Light Linking und Parti Volume
Bei der Verwendung eines Parti-Volume-Shader66 zur Berechnung von

volumetrischem Licht kam es ebenfalls zu einem sehr eigensinnigen Bug. Der Nebel
renderte auf meinem Heimsystem problemlos.
Wenn auf der Farm gerendert wurde, fingen die PCs zwar an zu rendern, aber mit
einer CPU-Auslastung von maximal 3%. Nach ungefähr 60min brach dann dieser
Vorgang ab, mit der Fehlermeldung, dass der Rendervorgang angehalten worden
sei.
Also musste die gesamte Szene debuggt werden, um herauszufinden, was die
Rendernodes anders machten.
Dabei lieferte Mental Ray® einen Lightlinking-Fehler, welcher auf dem x64-System67
auftrat, aber der keine Probleme machte.
Alle Lichter innerhalb der Szene, welche sich nicht auf dem aktuellen Renderlayer
befanden, lieferten dabei den Fehler.
Es ist völlig normal, innerhalb eines Renderlayers nur einige Szenenlichter zu
verwenden.
Mein Workaround dafür bestand darin, alle Lichter, welche nicht mit in das
Rendering einfließen sollten, auf den aktuellen Renderlayer hinzuzufügen und deren
Intensität mittels Layer Overrides68 auf 0 zu stellen.
Es dauerte einige Stunden diesen Fehler zu debuggen.
4.6.4.1 IPR MAYA
IPR69 innerhalb von Maya bietet den Vorteil, einer Vorschau des gerenderten Bildes
zu erstellen und somit die schnelle Feinjustierung einzelner Parameter zu ermöglichen.
Dabei kann IPR sowohl mit dem Maya Softwarerender als auch mittels Mental Ray®
durchgeführt werden. IPR in Verbindung mit Maya-Software bietet den Nachteil,
dass keine Möglichkeit zum Raytracing besteht. Da die Szenen auf Mental Ray®
aufgebaut sind, war dies keine weitere Hürde. Das Problem daran ist, dass Mental
Ray® extrem instabil in Maya implementiert wurde. Bei nahezu jedem IPR kam es
mittels Mental Ray® zu Problemen, die von Anzeigefehlern bis hin zu kompletten
Softwareabstürzen reichten.
Um Datenverluste dabei so gering wie möglich zu halten, wurde jeweils vor jedem IPR
eine Sicherung des Projektes angelegt.
66 Volumetrischer Shader für Berechnung von diversen Lichteffekten

67 64 Bit Betriebssystem
68 Wertüberschreibungen mit einem Gültigkeitsbereich innerhalb des Layers
69 IPR (Interactive Photorealistic Rendering), dient zur schnelleren Vorschau des gerenderten
Bildes
4.6.4.2 Royal Render Bugs
Nachdem die Farm installiert war, kamen die ersten Bugs zum Vorschein. Maya bietet
in seiner 2009 Edition die Möglichkeit, einzelne Renderpässe als neue Bildsequenzen
aus dem Framebuffer von Mental Ray® zu erstellen. Dieses Feature spart enorme
Renderzeiten, da nicht jeder einzelne Pass erneut berechnet werden muss, sondern
mehrere Renderpässe mittels eines Rendervorgangs generiert werden können. Dieses
neue Feature wurde von Royal Render zwar unterstützt, jedoch waren die
Pfadangaben beim Renderstart nicht mehr korrekt. Somit wurde das Feature in
Zusammenhang mit Royal Renderer unbrauchbar. Dennoch sollte es genutzt
werden, weshalb direkt Kontakt mit der Herstellerfirma der Software hergestellt
wurde.
Es dauerte genau 3 Tage, bis diese ein Update herausbrachte, in welchem unter
anderem mein Problem gefixt70 wurde.
Der einzige Renderbug, welcher während meiner Arbeitszeit nicht behoben wurde,
tritt auf, wenn innerhalb von Maya mehrere renderbare Kameras definiert werden.
Dann kommt es nach wie vor zu Pfadproblemen. Es lässt sich jedoch sehr wohl nur
eine Kamera definieren und während des Absendens des Renderauftrages mehrerer
Kameras und deren Framebereiche überschreiben, sodass dieser Bug leicht
umgangen werden kann.
4.6.5 Freitag der 13.
Ohne eine Form von Aberglaube zum Ausdruck zu bringen, hatte es dieser Freitag
der 13.03.09 in sich. An dem Tag ereigneten sich definitiv die meisten zufälligen Fehler
während des gesamten Projektes. Während die letzten Szenen vorbereitet wurden,
bekam mein Heimsystem plötzlich ein sehr hohes Maß an Instabilität. Vorher war die
Nutzung monatelang ohne jegliche Probleme möglich.
Nach einigen Diagnosen stellte sich heraus, dass die Systemfestplatte defekte Blöcke
beinhaltete und somit einen Hardwareschaden aufwies. Auf dem Laufwerk waren
sämtliche Programme sowie Windows gespeichert. Projektdaten standen weiterhin
mittels Back-up zur Verfügung, aber die defekte Hardware musste ausgetauscht und
neu installiert werden. Die Analyse und Behebung des Fehlers kostete ungefähr zwei
Tage. Ein Stromausfall innerhalb des HTW Geländes Wilhelminenhof an diesem Tag
sorgte ebenfalls für etwas mehr Verzug. Nachdem sämtliche Rechner und der
Fileserver durch den Ausfall lahmgelegt waren, kam es zu weiteren Fehlern.
Unter anderem gab es nun mehrere defekte Schreibvorgänge von gerenderten
Bildern, welche per Hand ausselektiert werden mussten. Außerdem musste erneut
zum Gelände der HTW gefahren werden um die Rechner neu zu starten, sowie die
Server auf Fehler zu prüfen.
70 Beseitigung eines Problems.

Nachdem der Strom wieder freigeschaltet war, starteten alle Rechner gleichzeitig,
wodurch mehrere Steckdosensicherungen der Labore rausgesprungen sind. Deshalb
wurden die Laborrechner vom System abgeklemmt und einzeln wieder aktiviert
werden. Anschließend war die Funktionalität aller Rendernodes wieder gegeben.
Ein weiteres Problem (durch den Ausfall ausgelöst) war, dass seit dem Ausfall das
Raid-System innerhalb des Fileservers nicht mehr synchronisieren konnte, was zur
Verwendung von nur noch einer Festplatte ohne eine Form von Back-up-Spiegelung
führte. Dies beunruhigte mich dermaßen, dass ein weiteres externes Laufwerk
innerhalb der Räumlichkeiten der HTW als Back-up-System für das Projekt gekauft
wurde.
Fazit 104
5 Fazit
Ich denke, dass ich mit dieser Arbeit die umfassende Thematik erfasst habe und
möchte mich an dieser Stelle dafür bedanken, dass mir die Möglichkeit gegeben
wurde, meine Fähigkeiten auf dem Sektor von 3D Produktionen zu beweisen. Ich
selbst habe sehr viel während dieser Arbeit über die verwendeten Programme sowie
auch über mich gelernt.
Außerdem bin ich sehr froh darüber, mit dieser Arbeit einen Kurzfilm geschaffen zu
haben, der in meinen Augen einen produktiven Wert hat und mich in Zukunft auf
meiner Bewerbungsreise begleiten wird.
Eigenständigkeitserklärung 105
6 Eigenständigkeitserklärung
Diese Bachelor Thesis wurde von Sven Bliedung, Student des Internationalen
Studiengangs Medieninformatik an der Fachhochschule für Technik und Wirtschaft
Berlin, verfasst.
Der Autor bestätigt hiermit, dass die vorliegende Arbeit ohne fremde Hilfe,
eigenständig, unter teilweiser Bezugnahme der im Anhang angegebenen
Literaturquellen, erstellt wurde.
Berlin, den 30. März 2009

Abbildungsverzeichnis
Abbildung 1: Vergleich GPU vs. CPU _____________________________________________________ 8

Abbildung 2: Omni Emitter _____________________________________________________________ 11
Abbildung 3: direktionaler Emitter _______________________________________________________ 11
Abbildung 4: Surface Emitter ___________________________________________________________ 12
Abbildung 5: Curve Emitter _____________________________________________________________ 12
Abbildung 6: volumetrischer Halbkreis Emitter ___________________________________________ 13
Abbildung 7: Beispiel 2D Fluid Container mit Strömungssimulation _________________________ 16
Abbildung 8: 3D Fluid Container 8x19x8 _________________________________________________ 17
Abbildung 9: 3D Fluidsimulation einer Flamme ( Auflösung: 50x60x99 ) _____________________ 18
Abbildung 10: Drag Field _______________________________________________________________ 20
Abbildung 11: Radial Field______________________________________________________________ 21
Abbildung 12: Gravity Field _____________________________________________________________ 21
Abbildung 13: Vortex Field _____________________________________________________________ 22
Abbildung 14: Turbulence Field _________________________________________________________ 22
Abbildung 15: dummes Partikelsystem __________________________________________________ 24
Abbildung 16: intelligentes Partikelsystem _______________________________________________ 24
Abbildung 17: generiertes Mesh ________________________________________________________ 25
Abbildung 18: Cloth Simulation _________________________________________________________ 26
Abbildung 19: Softbodys _______________________________________________________________ 26
Abbildung 20: Geometrisches Verfahren ________________________________________________ 28
Abbildung 21: Mesh mit Partikel_________________________________________________________ 33
Abbildung 22: Structural Springs (links) und Shear Springs (rechts) _________________________ 33
Abbildung 23: NCloth Objekt mit Springs ________________________________________________ 34
Abbildung 24: Cloth Objekt mit Pin Constraint ___________________________________________ 34
Abbildung 25: Aufbau der Datenstruktur ________________________________________________ 45
Abbildung 26: Ist Zustand Renderfarm ___________________________________________________ 49
Abbildung 27: Remotezugriff Zugriff auf die Farm ________________________________________ 56
Abbildung 28: Render Pipeline__________________________________________________________ 61
Abbildung 29: Hauptcharakter Kaki _____________________________________________________ 63
Abbildung 30: Tisch mit Teeglas _________________________________________________________ 64
Abbildung 31: Modellierung auf Bildbasis, links Foto, rechts 3D Model _____________________ 65
Abbildung 32: Modellierung von Kleidung _______________________________________________ 65
Abbildung 33: gerenderte Kamera _____________________________________________________ 66
Abbildung 34: Beispiel: Teil des Shadingnetzwerks für die Dose ____________________________ 67
Abbildung 35: Dose gerendert _________________________________________________________ 67
Abbildung 36: Licht Setup Hof __________________________________________________________ 68
Abbildung 37: Erstellte Rigs _____________________________________________________________ 69
Abbildung 38: Walkcycle der Kakerlake in Keys __________________________________________ 70
Abbildung 39: Flyer und Fahne _________________________________________________________ 72
Abbildung 40: Flyer am Stein ___________________________________________________________ 73
Abbildung 41: Wellensimulation mit Schaum_____________________________________________ 74
Abbildung 42: Hintergrundcharaktere ___________________________________________________ 76
Abbildung 43: Frau mit Kamera _________________________________________________________ 77
Abbildung 44: Reißende Ringe _________________________________________________________ 78
Abbildung 45: Blumen gießen. __________________________________________________________ 80
Abbildung 46: Generierte Wolken_______________________________________________________ 81
Abbildung 47: Seitengasse _____________________________________________________________ 82
Abbildung 48: Kleiner Brunnen __________________________________________________________ 83

Abbildung 49: Fische im Brunnen _______________________________________________________ 84
Abbildung 50: Tee _____________________________________________________________________ 85
Abbildung 51: Rigid Body Simulation ____________________________________________________ 87
Abbildung 52: Berechnungsverlauf der Kellerwelle innerhalb der ersten 30 Stunden ________ 89
Abbildung 53: Simulation nach 40 Stunden ______________________________________________ 90
Abbildung 54: Frame 297 nach 60h Berechnung _________________________________________ 90
Abbildung 55: Frame 309 nach 100 Stunden _____________________________________________ 90
Abbildung 56: mip_motion_vector Node in Maya ________________________________________ 94
Abbildung 57: Connection Editor _______________________________________________________ 94
Abbildung 58: Legacy Output Shader ___________________________________________________ 95
Abbildung 59: Beauty Layer ____________________________________________________________ 96
Abbildung 60: Ambient Occlusion Layer ________________________________________________ 96
Abbildung 61: Masken Layer ___________________________________________________________ 96
Abbildung 62: Motion Vector Layer _____________________________________________________ 97
Abbildung 63: Depth Layer _____________________________________________________________ 97
Abbildung 64: finales Compositing ______________________________________________________ 97
Abbildung 65: Photonenberechnungsfehler (links), korrekt (rechts) ________________________ 99
Abbildung 66: Cachingfehler (links), korrekt (rechts)______________________________________ 99
Abbildung 67: Blockfehler (links), korrekt (rechts) ________________________________________ 100
Abbildung 68: Shadingfehler (links), korrekt (rechts) _____________________________________ 100
Literaturverzeichnis
André Gagalowicz, W. P. (2007). Computer vision/computer graphics, collaboration

techniques. In Computer vision/computer graphics, collaboration techniques (S. 139-
148). Frankreich: Springer.
Babic, K. (1999, April 28). Matthew Ward's Home Page. Retrieved Januar 2009, from
Matthew Ward's Home Page: http://davis.wpi.edu/~matt/courses/cloth/
Balázs, Ákos. (2008). Tessellation and rendering of trimmed NURBS models in scene
graph systems.
Brinkmann, R. (1999). The art and science of digital compositing. In R. Brinkmann, The
art and science of digital compositing (S. 141-170). Morgan Kaufmann.
Eric Keller, E. A. (2009). Mastering Maya 2009. In E. A. Eric Keller, Mastering Maya 2009
(S. 899-930). John Wiley and Sons.
Ericson, C. (2005). Real-time collision detection. In C. Ericson, Real-time collision

detection (S. 7-13). Elsevier.
Featherstone, R. (2008). Rigid Body Dynamics Algorithms. In R. Featherstone, Rigid

Body Dynamics Algorithms (S. 39). Springer.
Herta, D. C. (23. November 2004). Gamephysik - Simulating Physics. Abgerufen am

12. Januar 2009 von Simulation and Game Physics:
http://www.christianherta.de/lehre/gamePhysics.pdf
Kohlmann, K. (2007). Der computeranimierte Spielfilm. In K. Kohlmann, Der

computeranimierte Spielfilm (S. 191-193). transcript Verlag.
mental ray - Functional Overview. (13. Januar 2007). Abgerufen am 12. Januar 2009
von mental ray - Functional Overview:
http://www.mentalimages.com/fileadmin/user_upload/PDF/mental_ray_Functional_
Overview.pdf
mental ray. (12. Oktober 2007). mental ray - Production Shader Library. Abgerufen
am 25. Januar 09 von mental ray - Production Shader Library:
http://www.mentalimages.com/fileadmin/user_upload/PDF/production.pdf
Michael Bender, M. B. (2006). Computergrafik: Ein anwendungsorientiertes Lehrbuch.

In M. B. Michael Bender, Computergrafik: Ein anwendungsorientiertes Lehrbuch (S.
489-493). Hanser Verlag.
NVIDIA. (2008). The New "X" Factor Part 1: NVIDIA PhysX. Abgerufen am 15. Januar
2009 von The New "X" Factor Part 1: NVIDIA PhysX:
http://developer.download.nvidia.com/presentations/2008/NVISION/NVISION08_The
_New_X_Factor.pdf
NVIDIA. (Februar 2007). White Paper - Cloth Simulation. Abgerufen am Januar 2009
von White Paper - Cloth Simulation:
http://developer.download.nvidia.com/whitepapers/2007/SDK10/Cloth.pdf
Park, J. E. (2004). Understanding 3D Animation Using Maya. In J. E. Park,

Understanding 3D Animation Using Maya (S. 136-139). Springer.
Peter Shirley, M. A. (2005). Fundamentals of computer graphics. In M. A. Peter Shirley,

Fundamentals of computer graphics (S. 547-553). A K Peters, Ltd.
Peter Sloot, M. B. (1998). High-performance computing and networking. In M. B. Peter

Sloot, High-performance computing and networking (S. 262-273). Amsterdam:
Springer.
Philip Dutré, P. B. (2003). Advanced Global Illumination. In P. B. Philip Dutré,

Advanced Global Illumination (pp. 270-273). A K Peters, Ltd.
Pixar Animation Studios. (2001). Physically Based Modeling - Particle System

Dynamics. SIGGRAPH 2001. Pixar Animation Studios.
Randima Fernando, M. J. (2003). The Cg tutorial: the definitive guide to

programmable real-time graphics. In M. J. Randima Fernando, The Cg tutorial: the
definitive guide to programmable real-time graphics (S. 248-253). Addison-Wesley.
Schönherr, M. (2006). Maya 7 - Die Referenz. In M. Schönherr, Maya 7 - Die Referenz

(S. 179-252). Addision-Wesley Verlag.
Telekinesys Research Ltd, t/a Havok. (2009). HAVOK. Abgerufen am 15. Januar 2009
von HAVOK: http://www.havok.com
Wells, P. (2007). Animtion. Deutschland: Stiebner.

BA Thesis Sven Bliedung - Analyse Und Evaluation Von Anwendungsszenarien Dynamischer 3D Simulationen

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

BA Thesis Sven Bliedung - Analyse Und Evaluation Von Anwendungsszenarien Dynamischer 3D Simulationen

Hochgeladen von

Copyright:

Verfügbare Formate

Internationale Medieninformatik

Internationaler Studiengang Medieninformatik

Hochschule für Technik und Wirtschaft Berlin

1. Betreuer: Prof. Thomas Bremer

1.1 MOTIVATION .............................................................................................................................. 5

2.1 ENTWICKLUNG ............................................................................................................................ 7

3.1 ECHTZEIT ENGINES ..................................................................................................................... 36

4 ENTSTEHUNG DES FILMS: WITH FLOW ........................................................................................ 39

4.1 DER ANFANG ........................................................................................................................... 40

4.3.3.1 Ist Zustand ..................................................................................................................................... 49

4.6.3.1 Kaustische Photonenberechnungen ....................................................................................... 99

5 FAZIT ......................................................................................................................................... 104

6 EIGENSTÄNDIGKEITSERKLÄRUNG ............................................................................................ 105

Im ersten Abschnitt werden die Grundlagen der 3D-Simulationen dargestellt. Der

Dadurch, dass sich viele Szenarien viel kontrollierter in Computerumgebungen

Dabei werden vorhandene Lösungen analysiert und die daraus gewonnen

1 Softbody, eng: weicher Körper oder deformierbare Objekte

Fluid-Simulationen zählen erst seit kürzester Zeit zu den Berechnungssystemen, welche

2 GPU (Graphic Processing Unit) Vektorprozessor der Grafikeinheit

2004 2005 2006 2006 Q3 2007 2007 Q3 2008

GPU 7 43 160 250 475 1056 2400

Abbildung 1: Vergleich GPU vs. CPU 5

Während der QX97756 im Dualbetrieb die 60 Gigaflops-Grenze erreicht, liegen

NVIDIA entwickelte eine auf C basierende Spracherweiterung namens CUDA,

5 Daten direkt von den jeweiligen Herstellerseiten

2.2 Rigid Body Dynamics

Dabei werden hauptsächlich zwei physikalische Betrachtungsweisen verwendet:

Die Newtonsche Mechanik, welche die Bewegung von Körpern innerhalb

Die Lagrangesche Mechanik8, welche zur Vereinfachung physikalischer

Dabei kommt es in der Computersimulation meistens nicht auf die exakte

Da die Berechnungszeit der Simulation mit ansteigender Anzahl von

8 Benannt nach Joseph Louis Lagrange

Es gibt zwei mathematische Modelle, nach denen Fluid-Solver arbeiten, entweder

11 z. B. Wasser, Honig, Lava

2.3.2.1 Arten von Emittern

Omni Emitter: Es wird in alle Richtungen emittiert (Abbildung 2).

Abbildung 2: Omni Emitter

Directional Emitter: Es wird in bestimmte Richtungen emittiert (Abbildung 3 ).14

Abbildung 3: direktionaler Emitter

14 Richtungen der x-, y- und z-Achse

Surface Emitter: Ausstoß erfolgt aus einem Objekt (Abbildung 4).

Abbildung 4: Surface Emitter

Abbildung 5: Curve Emitter

Abbildung 6: volumetrischer Halbkreis Emitter

2.3.3.1 Objekt Constraints

Objekt Constraints werden zwischen unterschiedlichen Objekten oder

Übliche Verwendungen finden unter anderem:

Point Constraints: Bedeutet die Limitierung des Bereiches der Translation

Orient Constraints: Bedeutet die Limitierung der Rotation eines Objektes

Parent Constraints: Bedeutet die Limitierung auf die Translation und

Scale Constraints: Sorgt für eine Skalierungslimitation des Objektes

Aim Constraints: Rotationsattribute werden dahin gehend limitiert, dass

2.3.3.2 Cloth Constraints

Component to Component: bindet einzelne Objektelemente an ein weiteres

Point to Surface: bindet die einzelnen Cloth Elemente an Punkte eines

2.3.4 Voxel-basierte Systeme

In der Berechnung volumetrischer Körper stellen Voxel 16 eine nicht wegzudenkende

Voxel-basierte Systeme werden innerhalb eines sogenannten Containers simuliert.

2.3.4.1.1 2D Voxel Grid

Beispiel eines 2D- Fluid- Containers siehe Abbildung 7

Abbildung 7: Beispiel 2D Fluid Container mit Strömungssimulation

2.3.4.1.2 3D Voxel Grid

Abbildung 8: 3D Fluid Container 8x19x8