BA Thesis Sven Bliedung - 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

Internationale Medieninformatik HTW Berlin

Bachelor Thesis Analyse und Evaluation von Anwendungsszenarien dynamischer 3D Simulationen

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.

6 Einleitung

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

7 Grundlagen

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.

8 Grundlagen

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

2004 2005 2006 2006 Q3 2007 2007 Q3 2008

GPU 7 43 160 250 475 1056 2400CPU 4,1 6,1 8,1 14,2 48 60

X850 X18001950 XTX

HD2900

HD3870

P4 Pentium D Core 2 Duo2x QX97700

500

1000

1500

2000

2500

3000

GFL

OPS

Zeitraum

9 Grundlagen

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.

10 Grundlagen

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.

11 Grundlagen

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

12 Grundlagen

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

13 Grundlagen

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

Abbildung 6: volumetrischer Halbkreis Emitter

14 Grundlagen

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.

15 Grundlagen

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.

15 Glue Strenght, engl. Klebkraft, definiert in Cloth Simulationen die Stärke des Zusammenhalts von Punkten.

16 Grundlagen

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.

17 Grundlagen

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

18 Grundlagen

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

19 Grundlagen

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.

20 Grundlagen

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

21 Grundlagen

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

22 Grundlagen

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

23 Grundlagen

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.

24 Grundlagen

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.

25 Grundlagen

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.

23 3D Objekt bestehend aus mehreren Polygonen 24 Gecachtes Mesh bezeichnet ein oder mehrere 3D Objekte, welche für jeden einzelnen Zeitabschnitt innerhalb eines Zeitraums auf einen Datenträger geschrieben wurde.

26 Grundlagen

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.

27 Grundlagen

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.

28 Grundlagen

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

29 Grundlagen

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).

30 Grundlagen

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

31 Grundlagen

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

32 Grundlagen

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.

33 Grundlagen

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)

34 Grundlagen

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.

35 Solver

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.

36 Solver

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)

37 Solver

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)

38 Solver

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.

30 Maya verfügt über mehre Solver und erweitert diese von Version zu Version. 31 Fü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.

39 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.

A B C D E F G HSELECTED

ON-LINE

A B C D E F G HSELECTED

ON-LINE

RS CS TR RD TD CDTALK / DATA

TALKRS CS TR RD TD CD

TALK / DATATALK

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.

39 MEL (Maya Embedded Language) 40 http://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.

41 Nodes 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.

47 Lokator 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.

104 Fazit

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.

105 Eigenständigkeitserklärung

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

Documents

Transcript of BA Thesis Sven Bliedung - Analyse und Evaluation von Anwendungsszenarien dynamischer 3D Simulationen