Vergleich von Automatisierungsmöglichkeiten für Textur Baking in Blender und Maya
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Vergleich von Automatisierungsmöglichkeiten für
Textur‐Baking in Blender und Maya
Studiengang Medieninformatik
Bachelorarbeit
vorgelegt von
Jakob Kübler
geb. in Gießen
durchgeführt bei der Firma
mi360 GmbH, Lich
Referent der Arbeit: Prof. Dr. Cornelius Malerczyk
Korreferent der Arbeit: M. Sc. Hans Cristian Arlt
Betreuer mi360 GmbH: Dipl.‐Ing. Michael Müller
Friedberg, 2020
Danksagung
Ich möchte an dieser Stelle den Personen, die die Entstehung dieser Bachelor Arbeit an vielen
Stellen betreut und begleitet haben, meinen Dank aussprechen:
Ich danke Prof. Dr. Cornelius Malerzyk für die Begutachtung der Arbeit, für die Anregun‐
gen in der Themensuche und Formulierung des Schwerpunkts.
Ich danke Hans Christian Arlt, der diese Arbeit als zweiter Referent beurteilt.
Ich danke Michael Müller von der mi360‐GmbH für die Betreuung der Arbeit und der
Bereitstellung aller benötigten technischen Ressourcen.
Ich danke Sophie Seip und Andre Rinn für ihre gewissenhafte Korrekturlesung.
Ich danke meinen Eltern für ihre uneingeschränkte Unterstützung, die weit über den Ab‐
schluss dieser Arbeit und dieses Studiums hinaus geht.
Ich danke Madeleine Seip, Niklas Rinn, Julia Bunke, Pascal Schüler und allen zuvor ge‐
nannten Personen für viele Gespräche bezüglich des Inhalts und der Form der Arbeit und für
viele Worte der Unterstützung.
Jakob Kübler
Friedberg, Dezember 2020
i
Selbstständigkeitserklärung
Ich erkläre, dass ich die eingereichte Bachelorarbeit selbstständig und ohne fremde Hilfe
verfasst, andere als die von mir angegebenen Quellen und Hilfsmittel nicht benutzt und die
den benutzten Werken wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich
gemacht habe.
Friedberg, Dezember 2020
Jakob Kübler
iii
Inhaltsverzeichnis
Danksagung i
Selbstständigkeitserklärung iii
Inhaltsverzeichnis v
Abbildungsverzeichnis vii
1 Einleitung 1
2 Verwandte Arbeiten 5
3 Grundlagen 7
3.1 Physically Based Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Shading Prinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Baking und Textursynthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Methodik 19
4.1 Ist‐Zustand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Entwicklung der Addons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1 Anforderungen an die Skripte . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Umsetzung Blender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.1 Vorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.2 Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.3 Benutzeroberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4 Umsetzung Maya . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.1 Vorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.2 Zugriff auf Materialien . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.3 Benutzeroberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5 Ergebnisse 39
5.1 Auswertung: Skript‐Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.1 Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.2 Datenzugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
v
INHALTSVERZEICHNIS
5.1.3 Baking‐Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1.4 Benutzeroberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Auswertung: Baking‐Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6 Ausblick und Zusammenfassung 47
A Anhang 49
A.1 Blender Code ‐ Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
A.2 Blender Code ‐ User Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . 56
A.3 Maya/Arnold Code ‐ Material Vorbereitung. . . . . . . . . . . . . . . . . . . . 60
A.4 Maya/Arnold Code ‐ User Interface . . . . . . . . . . . . . . . . . . . . . . . . 64
Bibliography 67
vi
Abbildungsverzeichnis
1.1 Game‐Asset‐Pipeline; Quelle: https://druidstone-game.com/ . . . . . . . . . 2
1.2 Maps für die Darstellung einer Goldschale. . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Darstellung Input und Output des Frameworks von Hu et al. . . . . . . . . . . . . 6
3.1 Vergleich zwei Sphären geshaded im Metalness‐Workflow (links) und im Specular‐
Workflow (rechts) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 BRDF als Funktion der Lichtrichtung L und der Betrachtungsrichtung V, Grafik:
[Wat02] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Phong‐Modell Beleuchtungsanteile, Grafik: Wikipedia . . . . . . . . . . . . . . . . 11
3.4 Beispiel Subsurface Scattering, Grafik: Wikipedia . . . . . . . . . . . . . . . . . . 12
3.5 Strahlenverteilung innerhalb eines Materials, Grafik: [HK93] . . . . . . . . . . . . 12
3.6 Principled BSDF von Blender und aiStandardSurface von Maya/Arnold . . . . . . . 13
3.7 Konzeptionierte Shade‐Trees, Grafik: [Coo84] . . . . . . . . . . . . . . . . . . . . 14
3.8 Beispiel Shading‐Tree(l) und Renderergebnis(r). Nodes: a) Einzelwert, b) Re‐
chenoperation, c) Textur‐Node ‐ Schachbrettmuster mit vorgeschalteten d) UV‐
Koordinaten als Eingangsvektor, e) Shader‐Node ‐ Enthält die BSDF f) Material Out‐
put ‐ regelt Verbindung zum Objekt. . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.9 Shading Tree zum Erzeugen einer prozeduralen Bump‐Map. Die Noise‐Textur
nimmt Objektdaten als Initialisierungsvektor entgegen. Die erzeugte Textur wird
in einen Schwarz‐Weiß Farbverlauf übergeben, mit dem die Höhen und Tiefen an‐
gepasst werden können. Endpunkt ist eine Bump‐Node, die die eingehenden Daten
in eine Bump‐Map umwandelt. Die Oberfläche des Objekts wirkt dadurch unregel‐
mäßig. Render: Blender/Eevee . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.10 Durch Ändern eines Parameters, der Weißtöne in der Noise‐Map, wirken die Bump‐
Anteile nun wie herausgebrochene Stellen. . . . . . . . . . . . . . . . . . . . . . 16
3.11 Node‐Tree eines prozeduralen Mauer‐Materials. Quelle: youtuber ‐ Erindale . . . . 17
3.12 UV‐Mapping des Utah‐Teapots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.13 Gebakte Color‐Map und Rendering. . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1 Die Baking‐Funktion von Blender (links) und Maya/Arnold (rechts). . . . . . . . . . 22
4.2 Flussdiagramm Baking‐Prozess: Blender(l) und Maya/Arnold(r)
Orange: Vorbereitung; Grün: Prozess im Material; Blau: Nachbereitung . . . . . . . 23
vii
ABBILDUNGSVERZEICHNIS
4.3 Setup vor dem Baking‐Prozess für das Baken des Base‐Color‐Inputs des principled
BSDF‐Shaders: a) Ausgewähltes Objekt, b) ausgewählte Image‐Texture‐Node, c)
Baking‐Node, Material‐Shader, e) Hilfs‐Emit‐Node, f) Material Output, e) Baking‐
Property‐Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4 Präambel eines Blender Addons . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5 Grundgerüst des neuen Operators . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.6 Default‐Inputs und Hilfs‐Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.7 Eine Geometry‐Node mit mehreren Ausgängen. . . . . . . . . . . . . . . . . . . . 28
4.8 Material Slots eines Objekts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.9 Code bis zur Baking‐Funktion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.10 Grundaufbau einer UI‐Klasse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.11 Erstellen eines Int‐Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.12 Fertiges Addon eingebettet in das Property‐Panel der Cycles‐Engine. . . . . . . . . 32
4.13 ls()‐Funktion, Beispielargumente grenzen die Liste ein auf selektierte Objekte (sl),
die sich in einer DAG‐Hierarchie befinden (dag) und vom Typ ẞhapeßind. Die Kon‐
sole gibt die Shape‐Objekte der selektierten Meshes als Liste aus. . . . . . . . . . 33
4.14 Die neue Klasse Bakelist. Die Klasse erhält direkt eine Funktion zum Updaten der
Baking‐Passes. Diese werden im späteren Userinterface durch Betätigen von Check‐
Boxen hinzugefügt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.15 Verbindung eines Einzelwert‐Outputs mit einem RGB‐Input. . . . . . . . . . . . . 35
4.16 In dieser Funktion findet nach Bestimmen des Speicherorts und des Speicherna‐
mens der Baking‐Prozess mit Render‐To‐Texture statt. . . . . . . . . . . . . . . . . 36
4.17 Import der Bibliotheken und Initialisierung der Init() für die Benutzeroberfläche. . 36
4.18 Die doExport‐Methode wird beim Betätigen des Render‐Buttons ausgeführt. . . . . 37
4.19 Fertiges Addon eingebettet in das Render‐To‐Texture Fenser von Arnold/Utilities. . 38
5.1 Vergleich Youtube‐Suchanfragen Maya Python, Blender Python von Nov. 2019 bis
Nov. 2020; Quelle:https://trends.google.com/ . . . . . . . . . . . . . . . . . . . . 40
5.2 Operator‐Template im Skripting‐Bereich von Blender. . . . . . . . . . . . . . . . . 40
5.3 Vergleich Lesen/Schreiben von Daten. . . . . . . . . . . . . . . . . . . . . . . . . 41
5.4 Renderings am Objekt mit Test‐Texturen (Cylces l., Arnold r.) Texturen Quelle:
https://texturehaven.com/ . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.5 Ergebnis Render‐To‐Textue des blauen Würfels. Das Material des roten Würfels
überdeck Flächen, auf denen Schatten sein müssten. Die tatsächlichen Schatten
auf der Textur sind länger als zu erwarten wäre. . . . . . . . . . . . . . . . . . . . 45
A.1 Liste der Baking‐Passes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
A.2 Funktion zum Erstellen der Baking‐Bilder. . . . . . . . . . . . . . . . . . . . . . . 49
A.3 Code, um Zugriff auf die Materialien eines Objektes zu erhalten. . . . . . . . . . . 50
A.4 Funktion zum Isolieren der Nodes, deren Informationen gebaket werden sollen. . . 50
A.5 Funktion zum erstellen temporärer Nodes mit Default‐Werten. . . . . . . . . . . . 51
A.6 Ergänzung von getBakingNodes() (vgl. Abb. A.4) um ein else‐statement, für den Fall
dass einem benötigten BSDF‐Input keine Node zugewiesen wurde. . . . . . . . . . 51
A.7 Funktion, um den korrekten Otput einer Baking‐Node zu ermitteln. . . . . . . . . . 52
viiiAbbildungsverzeichnis
A.8 Funktion zur Erstellung der Texture‐Nodes im Material. . . . . . . . . . . . . . . . 52
A.9 Funktion zum Erstellen einer temporären Emit‐Shader‐Node. . . . . . . . . . . . . 53
A.10 Code der Baking‐Funktion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.11 Funktion zum Wiederherstellen der Materialien. . . . . . . . . . . . . . . . . . . 55
A.12 Anlegen der benötigten Properties zur Eingabe von Nutzer‐Daten. . . . . . . . . . 56
A.13 Registrieren der benötigten Properties und Anlegen eines Property‐Pointers. . . . 57
A.14 Draw‐Funktion des Haupt‐Panels. . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
A.15 Draw‐Funktion des Option‐Panels. . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.16 Draw‐Funktion des Export‐Panels. . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.17 Mit Register werden neue Funktionen in Blender dauerhaft angemeldet. . . . . . . 59
A.18 Funktion, die die Materialien des Objekts in ein Dictionary einfügt. . . . . . . . . . 60
A.19 Funktion, die die Baking‐Nodes ermittelt und gegebenenfalls erstellt. . . . . . . . 61
A.20 Setzen der Verbindungen der Baking‐Nodes zum Utility‐Shader und vom Utility
Shader zum Surface‐Shader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.21 Diese Funktion überprüft rekursiv, ob der Name der zu rendernden Map schon im
Zielverzeichnis vorhanden ist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.22 Die cleanUp Funktion setzt die Materialien in ihren Ausgangszustand zurück. . . . 63
A.23 Die Methode zum Bauen der Benutzeroberfläche des Bake‐PBR‐Fensters. . . . . . 64
A.24 Diese Methoden werden an die Check‐Boxen der Bake‐Passes gebunden und lösen
die updateBakeList()‐Funktion aus. . . . . . . . . . . . . . . . . . . . . . . . . . . 65
ixKapitel 1
Einleitung
Der PBR‐Workflow (Physically Based Rendering) hat sich in der professionellen 3D‐Entwicklung
in vielen Firmen durchgesetzt, da der Prozess leicht zu verstehen ist und stabile Arbeitsstruktu‐
ren bietet. Nach PBR zu arbeiten bedeutet, Renderings zu erstellen, die physikalisch plausibel
sind und für den Betrachter überzeugend wirken[PJH16]. Zusammengefasst hängt die Bildge‐
bung in der Computergrafik von drei Dingen ab: Der Lichtquelle, der Struktur, der betrachte‐
ten Oberfläche und der Position des Betrachters. Diese Beziehungen plausibel zu simulieren
ist das Ziel von PBR. Abgesehen von soliden Rechenmodellen für die Interaktion von Licht und
Oberflächen, liegt es an 3D‐Entwicklern die Oberflächen von Objekten, also ihre Materialien,
so überzeugend wie möglich zu gestalten. Dazu werden in der 3D‐Industrie viele spezialisierte
Lösungen angeboten.
Autodesk Maya und Blender sind 3D‐All‐In‐One‐Programme, mit dem Anspruch ihren Nut‐
zern einen vollständigen 3D‐Workflow zu ermöglichen. Maya ist seit Jahren der Industriestan‐
dart in der 3D‐gestützten Filmproduktion und ist an vielen Lehrinstituten das Programm, mit
dem professionelle 3D‐Entwickler ihre ersten Erfahrungen machen[Aut20a]. Mayas Kern ist ei‐
ne maximale Funktionalität, die versucht so viele Nutzer wie möglich zu erreichen. Im Gegen‐
satz zu Maya ist Blender ein Free‐Ware‐Programm[Fou20]. Es ist für Hobbyisten, aber auch viele
professionelle 3D‐Entwickler und ‐Künstler das Entwicklertool der Wahl. Es wirbt aktiv mit sei‐
ner Nutzerfreundlichkeit und den vielen online verfügbaren Lernressourcen. Beide Programme
erlauben mit ihrer jeweiligen Shading‐Funktion ebenfalls die Möglichkeit PBR‐Materialien zu
erstellen. Blenders Kombinationsshader pBRDF und der in Maya integrierte aiStandardSurface
der Render‐Engine Arnold[Sol20b], sind beides Shader, die auf PBR‐Prinzipien beruhen.
Der Shading‐Workflow beider Programme erlaubt eine große Kontrolle und kreativen Aus‐
druck. Umfangreiche Node‐Netzwerke für prozedurale Shader können in beiden Programmen
erstellt werden. Die Prinzipien sind jeweils ähnlich und die Ergebnisse vergleichbar. Die Nut‐
zung der erstellten Materialien funktioniert innerhalb von Maya und Blender sehr gut. Schwie‐
rigkeiten treten auf, wenn diese Programme nicht die Endanwendung zur Darstellung eines
3D‐Objektes sind, sondern nur Teil eines größeren Workflows. Üblicherweise bedienen sich
Entwickler mehrerer Anwendungen, um Ergebnisse zu produzieren. Die Tabelle 1.1 und die Ab‐
bildung 1.1 zeigen einen typischen Workflow zum Modellieren und rendern von 3D‐Objekten
in Videospielen.
11. EINLEITUNG
Tabelle 1.1: Game‐Asset Pipeline
Konzept Photoshop, Ilustrator, ZBrush
High‐Poly Modeling ZBrush
Low‐Poly Modeling Maya, Blender
UV‐Mapping Maya, Blender
Normal Baking Maya, Blender
Texturing Substance Designer, Quixel Mixer
Animation Maya, Blender
Rendering Unity Engine
Abbildung 1.1: Game‐Asset‐Pipeline; Quelle: https://druidstone-game.com/
In der Industrie haben sich Workflows etabliert, in denen Dritt‐Software wie Substance‐
Painter ubiquitär verbreitet sind. Diese Programme sind unbestreitbar effizient in ihrer Funkti‐
onsweise und ihre Nutzung wird in der 3D‐Szene von vielen Entwicklern beworben und von den
meisten Firmen gefordert. Die Verwendung von Dritt‐Software zur Problemlösung hat prakti‐
sche Gründe. Während 3D‐All‐In‐One Software die Möglichkeit eines abgeschlossenen Work‐
flows wie eben beschrieben bietet, sind spezialisierte Programme meist funktionsreicher und
intuitiver in ihrer Nutzung. Häufig ist mit weniger Zeitaufwand ein äquivalentes, oder besseres
Ergebnis zu erzielen.
Die Nutzung von weiterer Software verlangt von Entwicklern eine zusätzliche Investition
von Geldern und Arbeitszeit, um ihre Mitarbeiter zu schulen und Programmlizenzen zu erwer‐
ben. Entsprechend müssen Firmen abwägen, welche Programme für ihren Workflow essenziell
sind, und welche Funktionalität mit Maya oder Blender ausreichend abgedeckt ist. Die Program‐
me sind für das Arbeiten in einem PBR‐Workflow gut ausgestattet. Die großen Kombinations‐
shader sind intuitiv benutzbar und erlauben die Erstellung von nicht‐destruktiven, prozeduralen
2Materialien12 . Die umfangreichen Möglichkeiten des Shadens in Maya und Blender stehen aber
in auffälligen Kontrast zur Möglichkeit diese Materialien in Form von Texture‐Maps außerhalb
der Programme zu nutzen. Texture‐Maps hatten schon immer eine große Bedeutung in der
3D‐Visualisierung. Sie sind einfach in der Handhabung, flexibel für die entsprechende Arbeit
nutzbar und bieten die Möglichkeit viele Details mit wenig Speicherplatz darzustellen. Außer‐
dem lassen sie sich sehr einfach programmübergreifend nutzen. Dies hat sich auch im nun weit
verbreiteten PBR‐Workflow nicht geändert. Häufig werden nur wenige Maps benötigt, um ein
überzeugendes Material darzustellen[AHH08].
Abbildung 1.2: Maps für die Darstellung einer Goldschale.
Die bereitgestellten Möglichkeiten von Maya und Blender generierte Materialien als
Texture‐Maps zu exportieren, sind nicht für Projekte mit vielen Texture‐Maps geeignet. Ma‐
ya/Arnold „Render to Texture“ und Blender „Bake Maps“ erlauben jeweils nur die Generierung
einer einzelnen Map, bevor der Workflow wiederholt werden muss. Der Mangel an Funktiona‐
lität ist aber nicht auf eine schlechte Qualität der errechneten Maps zurückzuführen, sondern
nur auf die Schwierigkeit der Bedienung. Die benötigte Zeit zum Erstellen und Exportieren von
Texture‐Maps ist linear zur gewünschten Anzahl. Das heißt, je mehr Materialien und unter‐
schiedliche Maps man exportieren möchte, desto mehr Zeit muss man aufwenden. Dies führt
zu einem unflexiblen Workflow, in dem Änderungen an Modell und Material viel Arbeitsauf‐
wand darüber hinaus generieren. Außerdem handelt es sich um eine sehr repetitive Arbeit, die
die stetige Aufmerksamkeit des Entwicklers erfordert.
Um diesen Umständen praktisch zu begegnen, empfiehlt sich die Entwicklung von Auto‐
matisierungsskripten, die repetitive Klickarbeit übernehmen und bei solider Programmierung
die Fehleranfälligkeit reduzieren. Blender und Maya bieten umfangreiche Möglichkeiten die
Nutzeroberfläche zu individualisieren und eigene Programmfunktionen zu erstellen. Beide stel‐
len eine interne Programmieroberfläche zur Verfügung. Um die Potentiale des PBR‐Texture‐
Bakings in Blender und Maya besser einordnen zu können, untersucht diese Arbeit wie gut
sich der Prozess im jeweiligen Programm automatisieren lässt. Zu diesem Zweck wird jeweils
1
www.blender.org, abgerufen am 01.12.2020
2
docs.arnoldrenderer.com, abgerufen am 01.12.2020
31. EINLEITUNG
ein Addon für Blender und Maya entwickelt, dass den limitierten Textur‐Baking‐Prozess bei‐
der Programme automatisiert und nutzerfreundlicher gestaltet. Beide Addons haben zum Ziel,
mit einem Knopfdruck den kompletten Textur‐Baking‐Prozess zu übernehmen. Dem Nutzer soll
ermöglicht werden, mehrere unterschiedliche Maps gleichzeitig zu generieren und zu exportie‐
ren. Zusätzlich soll es möglich sein, für mehrere Objekte gleichzeitig Maps zu generieren. Dies
wird über die Entwicklung einer Nutzeroberfläche ermöglicht, die es auch Nutzern mit wenig
Programmierkenntnissen erlaubt die Skripte zu nutzen.
Zur Auswertung dient als Basis eine 3D‐Szene, die auf möglichst ähnliche Art und Weise
in beiden Programmen geshaded wird. Es wird ausgewertet, inwieweit die Anforderungen des
PBR‐Workflows im jeweiligen Programm durch ein Skript unterstützt werden können, welche
Unterschiede in der Umsetzung auffällig sind, sowie bildliche Unterschiede in den erstellten
Maps und worauf sie zurückzuführen sind. Besonderes Augenmerk wird auf Limitationen in
der Umsetzung gelegt und wie bedeutend diese sind für einen erfolgreichen PBR‐Workflow.
Zuletzt wird eine Beurteilung erstellt, ob die Entwicklung von Automatisierungsprozessen für
eine mittelständische Firma einen Zeitgewinn darstellten kann.
4Kapitel 2
Verwandte Arbeiten
Die Prinzipien des Bakens haben sich seit der ersten Verwendung des Begriffs nicht geändert.
Baking ist weniger ein Ziel als ein populärer Workaround in der 3D‐Industrie, weswegen sich die
Forschung darauf richtet, die Probleme zu lösen, die mit Baken umgangen werden. Zusätzlich
konnte für den Bereich des Vergleichs von Programmfunktionen von 3D‐Programmen keine
Primär‐ und Sekundärliteratur finden lassen. Die geringe Verfügbarkeit von Literatur zeigt, dass
Forschung in diesem Bereich benötigt wird. Im Folgenden werden deswegen einige Studien
vorgestellt, die sich im Orbit einiger in dieser Arbeit gewidmeten Konzepte befinden und in
der Diskussion der Ergebnisse aufgegriffen werden. Die Studien beziehen sich auf die Nutzung
von Blender als alternative Plattform für professionelle Arbeiten in der 3D‐Industrie und der
Umsetzung des PBR‐Standards und auf die Generierung von Texturen im Allgemeinen.
Die Studie ’Medical image processing tools for Blender with HPC support’[Str+16] unter‐
sucht die Möglichkeit Blenders, auf Basis von CT‐Schicht‐Bildern eine 3D‐Rekonstruktion
durchzuführen. Das von ihnen entwickelte Plugin nimmt DICOM‐Dateien (Digital Imaging and
Communications in Medicine standard) entgegen, konvertiert sie in von Blender lesbare Bilder
und konstruiert daraus ein 3D‐Modell. Im Vergleich mit in diesem Bereich häufig genutzter
Software (3DSlicer, Osirix) schneiden die Möglichkeiten ihrer Plugins gut ab. Das Plugin soll
eine Alternative für medizinisches Personal darstellen, die mit 3D‐Rekonstruktionsdaten
arbeiten.
Jaros et. al[Jar+15; Jar+17] beschreiben die Möglichkeiten, die in Blender integrierte
Render‐Engine Cycles auf eine bestimmte CPU‐Konfiguration hin zu optimieren. Ihr Ziel ist eine
Alternative zu regulären CPU‐ und experimentellen GPU‐Renderings in Cycles zu entwickeln.
Das von ihnen entwickelte Plugin, auf Basis der OpenMP‐Schnittstelle für parallele Nutzung von
verschiedenen CPU‐Kernen, hat Renderzeiten in Offline‐Renderings und Echtzeit‐Renderings
um bis zu 50% im Vergleich zu gängigen CPU‐ und GPU‐Konfigurationen gesenkt.
In der Studie ’Real‐time Rendering of Procedural Multiscale Materials’[ZK16] wurde ein
Verfahren zur besseren Darstellung von Glanzlicht‐Highlights von prozeduralen Highlights
in einer Echtzeit‐Renderumgebung vorgestellt. Sie haben eine NDF (Normal Distribution
52. VERWANDTE ARBEITEN
Function) entwickelt, die eine gute Kontrolle über die Glanzlichteffekte von Materialien
erlaubt und auf globaler Ebene gute Effekte erzeugt, aber im Detail durch Künstler anpassbar
bleibt. Ihre Ergebnisse sollen vor allem bei der Darstellung von Glanzlicht‐Mikrodetails von
körnigen Materialien wie Sand und Schnee visuelle Effekte ermöglichen, die zuvor nur durch
Offline‐Rendering möglich gewesen sind.
Hu et al.[HDR19] stellen ein neues Framework zum Erstellen prozeduraler Materialien
vor, dass die Vorteile von pixelbasierter[EL99] und prozeduraler[Per85] Textursynthese kom‐
biniert. Ihr Modell baut auf der in der Praxis gemachten Erfahrung auf, dass Künstler bei der
Suche nach Materialien erst eine grobe Kategorie vorgeben(Stein, Mauer, Grass) und sich dann
in feinere Bereiche vorarbeiten. Ihr Framework erfordert die Eingabe eines Eingangsbilds und
die Bestimmung einer Kategorie, um daraus eine prozedurale Textur auf Basis des Eingangsbild
herzustellen. Das Modell erstellt automatisch Maps nach PBR‐Standard und lässt über die
Initialeingabe Veränderungen zu.
Sturm et al.[Stu+16] beschreiben 2016 ein Framework für die Darstellung von PBR‐Materialien
in WebGL. Der von ihnen entwickelte Shader orientiert sich an den PBR‐Prinzipien die Disney
in den vorherigen Jahren für ihre Produktionen formuliert und implementiert hat[BS12;
Bur15]. Sie sprechen sich für eine flächendeckende Implementierung des Metalness/Rough‐
ness Workflows aus, um die Ziele von PBR in WebGL zu verwirklichen. Sie entwickeln eine
Zusatzfunktion zum gLTF‐Format, dass dazu in der Lage ist PBR‐Materialien zu erkennen und
an eine Shading‐Engine auf OpenGl‐Basis zu übergeben.
Abbildung 2.1: Darstellung Input und Output des Frameworks von Hu et al.
6Kapitel 3
Grundlagen
3.1 Physically Based Rendering
Für die Darstellung von 3D‐Objekten sind in der Computergrafik drei Parameter von fundamen‐
taler Bedeutung: Die Lichtverhältnisse des Raums, die Oberflächenstruktur des Objekts und die
Position des Beobachters. Damit ein Objekt für einen Betrachter sichtbar ist, muss es so be‐
leuchtet werden, dass einige vom Objekt reflektierte Strahlen direkt in Richtung des Beobach‐
ters abgehen. Der zweite Punkt ist die Oberflächenbeschaffenheit des Objekts, dem Material.
Das Material bestimmt in welcher Art Licht an der Oberfläche reflektiert wird. Glatte Oberflä‐
chen absorbieren wenig und reflektieren viel Licht in eine Richtung, was zu Glanzlichteffekten
führt und zu Spiegelverhalten. Unregelmäßige, raue Oberflächen streuen Licht hingegen in vie‐
le verschiedene Richtungen und absorbieren einen hohen Anteil, weswegen ihre Oberfläche
einen gleichmäßigen Farbverlauf haben.
Die Beziehung zwischen Beobachter, Beleuchtung und Material so zu simulieren, dass
die entstehenden Bilder dem entsprechen was wir in der Realität erwarten, ist das Ziel des
PBR‐Workflows[PJH16]. PBR steht für Physically Based Rendering und ist ein Render‐Workflow
und eine Design‐Philosophie, die um die Jahrtausendwende zunehmend an Relevanz gewinnt.
PBR ist nicht genau definiert, sondern ist ein Schirmbegriff für viele Techniken in der 3D‐
Visualisierung, die alle gemein haben, überzeugende Bilder zu produzieren, indem sie sich auf
physikalische Gesetzmäßigkeiten beziehen. Der PBR‐Workflow hat sich als Industriestandart
sowohl in der 3D‐Industrie für Film und Animation, als auch in der Herstellung von interaktiven
Echtzeitanwendungen wie Videospielen und webbasierten Anwendungen durchgesetzt.
Das wichtigste Prinzip des PBR‐Workflows ist eine realistische beziehungsweise glaubhaf‐
te Darstellung von Materialien und Lichtverhältnissen. Der Workflow soll es 3D‐Künstlern und
Entwicklern erlauben, sich auf die Qualität von Materialien zu konzentrieren, sowie vorherseh‐
bare Ergebnisse in unterschiedlichen Lichtverhältnissen zu generieren. Die Beleuchtung eines
Objekts und die sich daraus ergebene Sichtbarkeit hängt nicht nur von direkten auf es scheinen‐
den Lichtquellen ab, sondern auch von den Lichtstrahlen, die durch andere Objekte reflektiert
werden ‐ indirektes Licht. Da alle Oberflächen einen gewissen Teil des auf sie eintreffenden
Lichtes reflektieren, muss eine Render‐Engine für alle Flächen in der Szene ermitteln, inwie‐
weit von dieser Fläche reflektiertes Licht in erster, zweiter... n‐ter Ordnung andere Objekte be‐
73. GRUNDLAGEN
leuchtet[Kaj98]. Da die Anzahl an möglichen Reflexionen in einer Szene gegen unendlich geht,
haben die für eine realistische Lichtstimmung erforderlichen Berechnungen, die Leistung der
verfügbaren Computertechnik lange überschritten. Ältere Workflows, wie die Phong‐Shader
Renderpipeline[Pho75] begrenzen sich deswegen auf lokale Beleuchtungsmodelle. Ein lokales
Beleuchtungsmodell rendert die Objekte einer Szene isoliert von einander und fügt sie später
wieder zusammen. Dies bietet große Vorteile bei der Berechnungszeit der einzelnen Bilder. Es
bedeutet aber auch, um eine realistische Lichtstimmung zu erzeugen, müssen Objekte entwe‐
der so geshadet und positioniert werden, dass fehlende Einflüsse durch andere Objekte nicht
auffallen. Wenn dies nicht möglich ist, müssen Unregelmäßigkeiten in der Postproduktion per
Hand bearbeitet werden. Fotorealistische und überzeugende Ergebnisse zu erzielen, ist damit
ein sehr aufwendiger Prozess. Erst um die Jahrtausendwende, mit der Entwicklung von spezia‐
lisierter Grafikhardware, die auch für Endnutzer verfügbar war, wurden Verfahren zur industri‐
ellen Nutzung von globaler Beleuchtung entwickelt[PJH16]. In den 1990gern produzierte Blue
Sky Studios die ersten kommerziell hergestellten Videos mit PBR als Grundlage. Blue Sky mach‐
ten ihre Verfahren aber nicht Publik, was die industrieweite Umsetzung verzögerte[Ohm97].
1999 lieferten Heidrich und Seidel einen alternativen Workflow zum nach wie vor großflächig
eingesetzten Phong‐Shading. Sie argumentierten, dass Computerhardware mittlerweile dazu
in der Lage sei, Millionen von Polygonen darzustellen und deswegen weitere Rechenleistung
vor allem in die Verbesserung der Qualität der Bilder gesteckt werden sollte. Sie stellen einen
Workflow für lokale und globale Beleuchtung vor, der die physikalischen Parameter der Mate‐
rialien in der Szene in den Vordergrund stellt und somit auch bei sich ändernder Beleuchtung
vorhersehbare Ergebnisse erzeugt [HS99].
Einige Entwickler sehen Nachteile bei einem branchenweiten Wechsel auf physikalisch ba‐
sierten Rendertechniken. Ein großer Vorteil der Computergrafik besteht darin, Bilder zu ren‐
dern, die in der Realität nicht möglich sind und entsprechend nicht physikalisch korrekt sein
können. Das wachsende Bedürfnis der Filmindustrie, echt gedrehtes Filmmaterial mit CGI (Com‐
puter Generated Imagery) zu verbinden, erforderte stärkere Notwendigkeit für die Entwicklung
von physikalisch basierten Rendertechniken. Die Lichtstimmung an einem Filmset sollte mög‐
lichst 1:1 durch die Shader am 3D‐Objekt repräsentiert werden, um die generierten Bilder so
echt und überzeugend aussehen zu lassen wie möglich[Sno10].
PBR ist mittlerweile nicht mehr als Neuheit anzusehen, da die Ideen und die Techniken von
den meisten Firmen implementiert sind. Zu beachten ist, dass PBR keine allgemeine Technik ist,
sondern ein Ziel. Firmen und Entwickler haben für sich spezialisierte Lösungen entwickelt, um
ihren Vorstellungen von PBR zu näher zu kommen[BS12; Lan14; KG13]. Die Firma Disney hat
ihren 2012 veröffentlichten PBR‐Ansatz anhand einer Studie des Mitsubishi Electric Research
Laboratories[Lab07] entwickelt. Die Studie hat mehrere Shading‐Modelle und ihre Fähigkeit
100 verschiedene Materialien darzustellen untersucht. Die Studie kam zu dem Schluss, dass
eine große Anzahl an Materialien durch die etablierten Shading‐Modelle nicht realistisch dar‐
gestellt werden können. Disney ist mit ihrer Studie zusätzlich zu dem Schluss gekommen, dass
ein exakt physikalisches Ergebnis nicht notwendig ist, sondern dass ihre Bilder lediglich phy‐
sikalisch plausibel für den Betrachter sein müssen. Sie erlauben sich dadurch einen höheren
Grad an künstlerischer Freiheit und verminderte Komplexität beim Erstellen von Materialien.
Die flächendeckende Implementierung von PBR in kommerziell genutzte Render‐Engines
verlief in Inkrementen über die letzten 20 Jahre. Auf einer praktischen Ebene haben
83.1. Physically Based Rendering
Abbildung 3.1: Vergleich zwei Sphären geshaded im Metalness‐Workflow (links) und im
Specular‐Workflow (rechts)
sich die Grundregeln des Shadens für Entwickler dadurch aber wenig verändert. Den
größten Unterschied den PBR in der Praxis macht, ist die Adaption des sogenannten
Metalness/Roughness‐Workflows als Alternative zum Specular/Gloss‐Workflow[Nic18; KG13;
Ste16]. Der Specular/Gloss‐Workflow setzt für eine Totalreflexion eines Material vorraus, dass
die diffuse Komponente des Materials komplett schwarz ist, also keinerlei Farbinformationen
beinhaltet. Um dennoch spiegelnde Materialien mit Grundfarbe, wie einige Metalle, darzustel‐
len, können mehrere Specularity Shader übereinander gelegt werden, um einen entsprechen‐
den Effekt zu erzielen (vgl. Abb. 3.1).
Beim Metalness/Roughness‐Workflow werden feste Materialien in zwei aus der Physik be‐
kannte Kategorien aufgeteilt: Dielektrika (nicht leitende Materialien) und Metalle. Metalle ha‐
ben die Eigenschaft, dass reflektierte Lichtstrahlen in der Farbe des Metalls reflektiert werden.
Durch die Ergänzung eines Shaders um eine Metalness‐Komponente müssen Künstler lediglich
bestimmen, ob das Material ein Metall ist oder nicht. Der Shader berechnet die Glanzlichtfarbe
dann anhand der Farbe des diffusen Kanals.
Der Vorteil des Metalness/Roughness‐Workflows ist, dass ein Material als metallisch de‐
finiert werden kann und der Shader den Rest übernimmt. Bei nicht metallischen Materialien,
die dennoch eine Glanzlichtkomponente haben (z.B. Plastik oder Glas), kann wieder über die
93. GRUNDLAGEN
Specular‐ und Roughness‐Komponenten des Shaders die Spiegelung bestimmt werden.
Der PBR‐Workflow ist nicht nur ein Ziel in der Film‐Industrie, sondern hat auch Einzug ge‐
funden in den Bereich des Echtzeit‐Renderings. Die Game‐Engines Unreal und Unity bieten
ihren Nutzern die Arbeit mit PBR‐Shadern[Gam20; Uni20]. PBR in Echtzeit‐Umgebungen hat
ähnliche Ansprüche wie in einer Offline‐Umgebung, verzichtet aber Leistungsbedingt auf vie‐
le Funktionen wie zum Beispiel Subsurface‐Scattering. Dennoch ist der Workflow mittlerweile
so verbreitet, dass der Umstieg auf eine andere Render‐Engine bei einem erfahrenen Künstler
nicht bedeutet den kompletten Prozess neu zu erlernen. Die fast branchenweite Implementie‐
rung ermöglicht ein hohes Maß an Austausch von Ressourcen zwischen den Programmen.
Die Nutzung von Texturen, für eine realistischere Darstellung von Objekten im 3D‐Raum,
ist seit dem Shading‐Modell von Phong integraler Bestandteil des Shading‐Prozesses[PJH16].
Die Art der verwendeten Texturen hat sich mit dem Wechsel auf eine PBR‐Umgebung ver‐
ändert. Man spricht vom Wechsel des Specular/Gloss‐Workflows zum Metalness/Roughness‐
Workflow[Nic18]. Ein Großteil der Oberflächendarstellung im PBR‐Workflow findet über fünf
Kanäle eines PBR‐Shaders statt. Grundfarbe (Base Color), Metalartigkeit (Metalness), Glanz‐
licht( (Specularity) Rauheit (Roughness) und Oberflächenreliefs (Normal/Bump), sind die am
meisten benutzten Parameter eines PBR‐Shaders und sind bedeutsam für Offline‐ wie Echtzeit‐
renderings.
3.2 Shading Prinzipien
In der Realität stellen sich Objekte dem Auge des Betrachters anhand der Lichtstrahlen dar,
die von der Objektoberfläche in Betrachtungsrichtung ausgesendet werden. Die Anzahl und
die Wellenlänge der reflektierten Strahlen bestimmen wie das Aussehen des Objekts vom Be‐
trachter wahrgenommen wird. Dieses Verhalten zu simulieren, ist ein wichtiger Bestandteil der
Computergrafik und dementsprechend ein Gebiet auf dem viel geforscht wird. Das Reflexions‐
verhalten einer Objektoberfläche oder Materials zu simulieren, funktioniert nur näherungswei‐
se, da mathematische Formeln nicht alle Vorgänge und Abweichungen bis auf die molekulare
Ebene abbilden können. Die Reflexion an einer idealen Oberfläche wird mit einer Bidirektionale
Reflexionsverteilungsfunktion (BRDF) ermittelt. Allen BRDF liegt eine 4‐dimensionale Funktion
aus dem Einfallswinkel des Lichts und dem Blickwinkel des Betrachters zu Grunde. Physikalische
Ansätze erlauben es jedoch, Materialdaten aus der Realität, wie die zuvor genannte Leitfähig‐
keit von Metallen, in eine Shading‐Funktion zu übergeben und daraus das Reflexionsverhalten
zu bestimmen. Alle möglichen Parameter zu ermitteln und in eine Funktion einzubinden, über‐
steigt jedoch die praktisch nutzbare Rechenleistung von Computern[Wat02].
Die Forschung in der Computergrafik hat diese Funktion immer wieder erweitert und opti‐
miert. Die wichtigsten Meilensteine werden im Folgenden kurz vorgestellt.
Verbreitete praktische Nutzung erlangt erstmals das Phong‐Modell[Pho75]. Es ist aufgrund
seiner guten Rechenleistung lange Zeit der Standard beim Rendern von 3D‐Szenen gewesen
und wird heute noch verwendet. Das Modell macht zwei Annahmen: Licht, dass von einer Flä‐
che reflektiert wird, hat eine diffuse‐ und eine Glanzlicht‐Komponente. Während Phong sich
für den diffusen Teil des Lichtes der Lambert‐Beleuchtungsformel bedient, entwickelt er eine
eigene Formel zur Simulation von Glanzlicht. Die Lichtstärke eines Punkts an einer Oberfläche
103.2. Shading Prinzipien
BRDF = f (θin, ϕin, θref, ϕref ) = f (L, V ) (3.1)
Abbildung 3.2: BRDF als Funktion der Lichtrichtung L und der Betrachtungsrichtung V, Grafik:
[Wat02]
ist nach Phongs Modell die Summe aus der diffusen Reflexion, dem Glanzlicht und der Umge‐
bungsbeleuchtung.
Abbildung 3.3: Phong‐Modell Beleuchtungsanteile, Grafik: Wikipedia
Das Phong‐Modell ist kein physikalischer Ansatz. Die Materialkonstanten der Formel reprä‐
sentieren keine Werte eines echten Materials, sondern werden arbiträr vom Entwickler be‐
stimmt. Es ist theoretisch möglich die Materialkonstanten so zu wählen, dass die Oberfläche
mehr Licht reflektiert als ihr zugefügt wird. Entsprechend folgt das Phong Modell nicht dem En‐
ergieerhaltungssatz [Geb03]. Der Phong BRDF ist gut dazu geeignet, diffuse und plastikähnliche
Materialien darzustellen, überzeugt aber nicht bei der Visualisierung von metallischen Mate‐
rialien[Fol+13].
J. Blinn modifiziert das Phong Modell, um die Oberflächenreflektion bei spitzen Betrach‐
tungswinkeln realistischer zu gestalten. Blinns Anpassungen machen das Modell zusätzlich
leichter zu berechnen [Bli77].
Cook & Torrance erweitern das Phong‐Modell, mit dem Ziel physikalische Eigenschaften von
Materialien besser darzustellen. Cook & Torrence entwicken eine Formel, die die Oberfläche
eines Materials als ein Feld von Mikrofacetten darstellt. Die Facetten sind V‐förmige, symme‐
113. GRUNDLAGEN
trische Vertiefungen in der Oberfläche, die eingehendes Licht vollreflektiert zurückstrahlen. Je
tiefer die Facetten, desto diffuser wirkt ein Material im Auge des Betrachters. Die Funktion er‐
laubt zusätzlich die Nutzung des Fresnel‐Wertes, für eine physikalisch basierte Lichtbrechung.
Die Ergebnisse von Cook & Torrance führen zu einer deutlich verbesserten Visualisierung von
metallenen Materialien wie Gold oder Aluminium [CT82].
Die BRD‐Funktion stellt bisher nur die Möglichkeit dar, Materialien als Lichtdurchlässig oder
undurchlässig zu betrachten. Diese Einteilung wird aber einigen Materialien wie Haut oder
Wachs nicht gerecht. Das sogenannte Subsurface Scattering sorgt dafür, dass Licht über den Ein‐
trittspunkt hinaus in das Material eindringt, und innerhalb dessen reflektiert (scattered) wird.
Je nach Dichte des Materials, können einige Strahlen das Objekt komplett durchdringen, wäh‐
rend andere durch die Eintrittsfläche zurück reflektiert werden [HK93].
Abbildung 3.4: Beispiel Subsurface Scatte‐ Abbildung 3.5: Strahlenverteilung inner‐
ring, Grafik: Wikipedia halb eines Materials, Grafik: [HK93]
Die stetig wachsenden Möglichkeiten des Shadens erhöhen auch die Komplexität und den
Produktionsaufwand. Die gängigen Arbeitsweisen in der 3D‐Produktion stützen sich entweder
auf Uber‐Shader oder Stacked‐Shader[Lan14]. Ein Uber‐Shader vereint verschiedene Shader‐
Funktionen in einer großen Funktion und ermöglicht die Manipulation der meisten Material‐
parameter an einer zentralen Stelle. Stacked‐Shader berechnen die Reflexionsanteile einzeln
und fügen sie im Nachhinein zusammen. Beide Wege bieten für unterschiedliche Produktio‐
nen Vorteile. Die Firma Disney entwickelte einen Uber‐Shader für ihre Produktionen. Der Uber‐
Shader‐Ansatz soll vor allem die Materialproduktion beschleunigen, neuen Mitarbeitern einen
leichten Einstieg bieten und schlussendlich die allgemeine Shader‐Qualität verbessern[BS12].
Der Disney‐BRDF ist nicht nur fester Bestandteil der Pixar Render‐Engine Renderman1 , son‐
dern wird von der Blender‐Foundation als Standard‐Shader in den Render‐Engines Cycles und
Eevee verwendet2 . Weitere Render‐Engines, wie zum Beispiel VRay3 und Redshift4 haben eige‐
ne Variante eines Uber‐Shader integriert. Die Firma Solid Angle integrierte nach einer eigenen
Studie 2014 ebenfalls einen Uber‐Shader in ihre Render‐Engine Arnold5 .
1
renderman.pixar.com, abgerufen am 12.10.2020
2
docs.blender.org, abgerufen am 12.10.2020
3
docs.chaosgroup.com, abgerufen am 12.10.2020
4
docs.redshift3d.com, abgerufen am 12.10.2020
5
docs.arnoldrenderer.com, abgerufen am 12.10.2020
123.3. Baking und Textursynthese
Abbildung 3.6: Principled BSDF von Blender und aiStandardSurface von Maya/Arnold
3.3 Baking und Textursynthese
Der Begriff des Bakens wird in der Computergrafik für viele Prozesse verwendet. Gemeinsam
haben sie, dass sie einen rechenintensiven dynamischen Wert, in einen rechenleichten stati‐
schen umwandeln6 . Die wichtigsten Anwendungsgebiete sind Animation, Physik‐Simulation,
Beleuchtung, Geometrie‐Baking und Texture‐Mapping.
Baking im Allgemeinen lässt sich gut anhand der Generierung einer Animation mittels einer
Physiksimulation veranschaulichen:
Das Zusammenspiel von vordefinierten Kräften in einer 3D‐Szene sowie der Masse und
anderen physikalischen Eigenschaften eines 3D‐Objekts, können mit wenigen Eingangspara‐
metern und geringer manueller Positionierung, realistische Animation erzeugen. Je nach Kom‐
plexität einer Simulation, ist es unpraktisch das exakte Verhalten eines Objekts vor dem Start
vorauszuberechnen. Deswegen finden Berechnungen zur Laufzeit der Simulation ab dem Mo‐
ment statt, in dem das System einer Veränderung ausgesetzt ist. Zum Beispiel kann in einem
6
docs.blender.org, abgerufen am 14.10.2020
133. GRUNDLAGEN
3D‐Programm das Rollen eines Steins simuliert werden, bei dem Parameter wie die Startge‐
schwindigkeit und die Richtung vom Entwickler bestimmt werden. Die Oberflächenbeschaffen‐
heit des Steins ist aber so unregelmäßig, dass die zum Schluss eingenommene Position nicht
vor Start berechnet werden kann. Die letzte Position ergibt sich aus zur Laufzeit immer wieder
stattfindenden Berechnungen. Während der Entwicklung von Echtzeit‐3D‐Anwendungen wie
zum Beispiel Computerspielen birgt eine Simulation viele Vorteile im Vergleich zu einer hän‐
disch produzierten Animation. Die Simulation benötigt relativ wenige Startparameter (im Falle
des Steins Geschwindigkeit und Richtung), um ein Objekt von A nach B zu bewegen. Von Nach‐
teil sind die andauernden Berechnungen während der Laufzeit, die eine Implementierung in
eine Echtzeit‐Anwendung unpraktisch machen kann. Um dies zu umgehen, wird die Simulati‐
on gebaked. Das bedeutet, die Simulation wird einmal bis zur Vollendung berechnet und die
aufgezeichnete Animation, also die festgehaltenen Positionsdaten des Steins zur Laufzeit, wird
gespeichert. Zukünftige Durchläufe der Animation erfordern also nicht mehr eine Berechnung,
sondern nur noch einen Aufruf der gespeicherten Positionsdaten, was eine deutlich schnellere
Operation darstellt.
Baking im Kontext dieser Arbeit ist als der letzte Schritt einer prozeduralen Textursynthese
mit anschließender Generierung eines Texturatlasses zu verstehen. Die Texturesynthese[EL99]
ist eine Teildisziplin der Computergrafik und die prozedurale Textursynthese eine Texturtechnik
in der 3D‐Grafik.
Abbildung 3.7: Konzeptionierte Shade‐Trees, Grafik: [Coo84]
Die prozedurale Textursynthese basiert darauf, dass durch Variation einer endlichen Anzahl
an Eingangsparametern eine unendliche Anzahl an Ergebnisvariationen erstellt werden kann.
Sie wird durch die scheinbar zufällige Musterbildung von verschiedenen Rauschfunktionen, wie
zum Beispiel Perlin‐Rauschen in Verbindung mit mathematischen Funktionen und Orts‐ bzw.
Richtungsvektoren ermöglicht[Per85].
Bei der Erstellung von prozeduralen Materialien hat sich die Arbeit mit Shading‐
Trees[Coo84] in der Industrie durchgesetzt. Ein Shading‐Tree stellt eine Nutzeroberfläche dar,
die es dem Anwender erlaubt alle den Shader beeinflussenden Werte, Operationen und Be‐
143.3. Baking und Textursynthese
rechnungen mit einem Diagramm einzusehen und zu manipulieren. Der Tree besteht aus Kno‐
ten, die Nodes genannt werden und deren Verbindungen untereinander eine Baumstruktur
bilden. Jede Node steht für einen in sich geschlossenen Prozess oder eine Funktion, die von an‐
deren Prozessen unabhängig ist, solange keine direkte oder indirekte Verbindung besteht. Die
einfachsten Nodes stellen nur einen für sich alleinstehenden Wert oder eine mathematische
Formel dar oder beinhalten die Informationen eines eingebundenen Bildes. Die Komplexität ist
allerdings nicht begrenzt und eine Node kann eine Vielzahl von Operationen beinhalten, mit
dem Ziel einen bestimmten Effekt zu erzeugen.
Abbildung 3.8: Beispiel Shading‐Tree(l) und Renderergebnis(r). Nodes: a) Einzelwert, b) Re‐
chenoperation, c) Textur‐Node ‐ Schachbrettmuster mit vorgeschalteten d) UV‐Koordinaten als
Eingangsvektor, e) Shader‐Node ‐ Enthält die BSDF f) Material Output ‐ regelt Verbindung zum
Objekt.
Nodes können vom Anwender frei eingefügt, ausgetauscht und verändert werden. So kön‐
nen ganze Stränge von Informationen, die in einen Shader fließen, voneinander isoliert und be‐
arbeitet werden. Durch die Verkettung verschiedenster Parameter ist es möglich, unterschied‐
lichste Oberflächenstrukturen zu generieren. Die Manipulation eines einzelnen Parameters be‐
sitzt dabei das Potenzial, große Veränderungen mit sehr geringem Aufwand zu erzeugen. Da‐
mit können prozedurale Texturen ohne auffällige Wiederholungen an jedes Objekt individuell
angepasst werden. Solche Texturen besitzen aber dieselbe Problematik wie die beschriebene
Physiksimulation. Wie sich die Textur tatsächlich darstellt wird während der Programmlaufzeit
berechnet und erfordert eine entsprechende Rechenleistung. Beim Erstellen aufwendiger wir‐
kender Materialien erhöht sich meistens die Komplexität der Shader‐Netzwerke.
Da jede verbundene Node am Endergebnis beteiligt ist, führt das Anpassen eines individuel‐
len Parameters zu einer Neuberechnung aller nachfolgenden Nodes. Bei großen Shading‐Trees
kann dies zu langen Berechnungszeiten führen. Gleichsam ungeeignete sind große Shading‐
Trees in Echtzeit‐Render Umgebungen, da jedes Frame eine neue Berechnung des Shaders er‐
fordert, auch wenn keine Werte direkt verändert werden. Gerade für Echtzeit‐Anwendungen
empfiehlt sich das Verwenden von statischen Bild‐Texturen, auf die die Render‐Engine nur im
Speicher zugreifen muss. Das Baken eines Shaders erlaubt es, wie in der oben beschriebenen
Physiksimulation, aus dem dynamischen rechenintensiven Prozess, ein statisches Bild zu gene‐
rieren. Die Lösung für diese Problematik ist das Baken der erstellten Textur, um aus dem dyna‐
mischen Prozess, ein statisches Bild zu gewinnen. Beim Textur‐Baking wird die finale Darstellung
der Textur in einer Bilddatei abgespeichert. Sie bleibt dadurch, von manueller Bildbearbeitung
153. GRUNDLAGEN
Abbildung 3.9: Shading Tree zum Erzeugen einer prozeduralen Bump‐Map. Die Noise‐Textur
nimmt Objektdaten als Initialisierungsvektor entgegen. Die erzeugte Textur wird in einen
Schwarz‐Weiß Farbverlauf übergeben, mit dem die Höhen und Tiefen angepasst werden kön‐
nen. Endpunkt ist eine Bump‐Node, die die eingehenden Daten in eine Bump‐Map umwandelt.
Die Oberfläche des Objekts wirkt dadurch unregelmäßig. Render: Blender/Eevee
Abbildung 3.10: Durch Ändern eines Parameters, der Weißtöne in der Noise‐Map, wirken die
Bump‐Anteile nun wie herausgebrochene Stellen.
einmal abgesehen, unveränderlich. Der Vorteil liegt auch hier in der Rechenoptimierung. Statt
zur Darstellung einer Textur eine lange und aufwendige Rechnung durchzuführen, greift der
Renderer lediglich auf den Speicherort der Textur zu und projiziert diese entsprechend des UV‐
Mappings auf ein Objekt [AHH08].
Der Variantenreichtum bei der prozeduralen Textur‐Synthese ist nicht der einzige Vorteil.
Beim Texturieren von 3D‐Objekten im 3D‐Workspace ermöglicht die Nutzung von lokalen Vek‐
toren als Texturparameter (z.B. Objektraum oder Objektposition) das Umgehen des 2D UV‐
Spaces. Im 3D‐Workspace werden alle Dimensionen des Objekts berücksichtigt und ein auf‐
wendiges Auffalten des Objekts in den UV‐Space ist nicht notwendig. UV‐Islands bilden dadurch
keine Seams und es ist dem Entwickler möglich, das UV‐Mapping auf minimale Verzerrung und
Platznutzung hin zu optimieren. Das eine UV‐Map vorhanden ist, ist dennoch für den Baking‐
Prozess unabdingbar. Die UV‐Map dient während des Baking‐Prozesses als „Form“ für die ent‐
stehende Map.
163.3. Baking und Textursynthese
Abbildung 3.11: Node‐Tree eines prozeduralen Mauer‐Materials. Quelle: youtuber ‐ Erindale
Abbildung 3.12: UV‐Mapping des Utah‐Teapots.
173. GRUNDLAGEN
Abbildung 3.13: Gebakte Color‐Map und Rendering.
18Kapitel 4
Methodik
Der Prozess des Shadings und Texturing ist in der Pra‐
xis nicht nur bestimmt durch die Fähigkeiten des an‐ Tabelle 4.1: Suchtreffer auf Art‐
wendenden Künstlers oder Entwicklers. Die Programmaus‐ station, gefiltert nach benutzter
wahl spielt eine wichtige Rolle, da Shading‐Programme und Texturing‐Software
Render‐Engines unterschiedliche Funktionen bieten und un‐
Substance 307648
terschiedliche Arbeitsweisen unterstützen. Im Bereich des
Shadings und der Materialerstellung sind die Programme Mari 13830
Substance Painter und Substance Designer von Adobe (2019 3D‐Coat 24042
übernommen von Allegorithmic) allgegenwärtig. Substance Mudbox 13989
Designer ist auf ArtStation1 und Sketchfab2 , den beiden Quixel 959
größten Seiten zum Vorstellen von 3D‐Kunst, der meistge‐
nannte Texture‐Painter zum Erzeugen von PBR‐Maps. Die Programme von Substance und Qui‐
xel sind von Haus aus auf die Shading‐Anforderungen des PBR‐Workflows ausgerichtet[Ado20;
Qui20]. Sie bieten nicht nur umfangreiche Möglichkeiten, 3D‐Objekte in einem Echtzeit‐
Showcase zu texturieren, sondern generieren beim Export der Materialien programmübergrei‐
fend nutzbare PBR‐Maps.
Die in dieser Arbeit zum Vergleich stehenden Programme Blender und Maya besitzen eben‐
falls umfangreiche Tools zum Shaden und zur Textur‐Synthese, die den PBR‐Workflow unterstüt‐
zen. Diese aber in ihrer Qualität und ihren Möglichkeiten PBR‐Maps zu erstellen einzuordnen,
ist aufgrund ihrer umständlichen Bedienbarkeit, die in diesem Kapitel noch genau skizziert wird,
sehr schwierig. Blender und Maya bieten allerdings beide umfangreiche Möglichkeiten, die Pro‐
grammfunktionen zu erweitern. Beide Programme nutzen Python als Skriptsprache, was einen
Vergleich der Funktion, PBR‐Maps zu erstellen gut möglich macht.
Ziel ist es also:
1. Für jedes Programm ein Addon auf Python‐Basis zu erstellen, dass den Baking‐Prozess,
bzw. PBR‐Map‐Export automatisiert.
2. Die Skripte auf ihre Erstellungsschwierigkeit und Nutzbarkeit hin zu vergleichen.
1
https://www.artstation.com/, abgerufen am 15.11.2020
2
https://www.sketchfab.com/, abgerufen am 15.11.2020
194. METHODIK
3. Die exportierten PBR‐Maps zu vergleichen und Unterschiede aufzudecken.
Um sich diesen Zielen adäquat zu widmen, ist es zuerst erforderlich, eine genaue Beschrei‐
bung des Ist‐Zustands der zu vergleichenden Programme aufzustellen. Die Erstellung der Ad‐
dons unterliegt in erster Linie den Entwicklungsvorgaben, die Maya und Blender ihren Nut‐
zern vorgeben. Da die Implementierung sich in vielen Aspekten stark unterscheiden kann, ist
es wichtig ein genaues Anforderungsprofil für die Addons zu definieren. Dies geschieht auf Ba‐
sis der im betrieblichen Umfeld aufgetretenen Herausforderungen beim Erstellen und Bear‐
beiten von PBR‐Maps mit Blender und Maya. Deswegen wird zuerst der Workflow zum Export
eines PBR‐Map‐Sets beider Programme in der Praxis skizziert, verglichen und analysiert. Aus
der Analyse werden Ziele für eine Vereinfachung des Vorgangs formuliert, um daraus anschlie‐
ßend einen Programmplan zu erstellen. Der Programmplan dient als Basis für die Umsetzung
im jeweiligen Programm.
4.1 Ist‐Zustand
Blender unterstützt von Haus aus zwei Render‐Enginges: Eevee und Cycles. Beide teilen sich
denselben Shading‐Workflow und dieselben Shading‐Nodes zum Erstellen von Materialien. Ee‐
vee ist allerdings eine Engine für Echtzeit‐Renderings, wohingegen Cycles ein Ray‐Tracer für
Offline‐Renderings ist. Die Möglichkeiten zum Baken sind nur mit Clycles verfügbar, was aber
praktisch keine Einschränkung darstellt, da sich beide Engines die Shading‐Nodes teilen. Bei
Maya verhält sich das anders. Maya bietet mit dem Turtle‐Plugin die Möglichkeit Texturen und
Maps zu baken. Der Workflow sieht allerdings die Übertragung von Maps von einem, auf ein
anderes Objekt vor und ist nicht geeignet für das Baken oder Simplifizieren von Shadern. Ar‐
nolds Utility‐Funktion, Render‐Selection‐To‐Texture, ermöglicht genau das. Dieses Tool der Ar‐
nold Render‐Engine baked den Output eines Shaders als Textur auf ein Bild, unter der Berück‐
sichtigung der UV‐Maps des Objekts. Die Funktionssweise gleicht der von Blender/Cycles. Die
Hauptshader von Blender (principled BSDF) und Arnold (AiStandardSurface) sind in ihrer Funk‐
tion und Bedienung sehr ähnlich, was einen Vergleich leichter macht.
Im Vergleich zu Maya benötigt Blender einige Vorbereitungen vor einem Baking‐Vorgang.
Blender benötigt ein vom Nutzer definiertes Bild, auf dem das Baking gerendert werden soll.
Dieses Bild muss in allen Materialien des Objekts eingebunden (aber nicht zwangsweise mit
dem Shader verbunden) und selektiert sein, bevor der Baking‐Vorgang gestartet werden kann.
Bilder werden entweder von Extern in die Szene importiert, oder direkt in Blender erstellt. Die
Dimensionen der Maps sind durch die Bildgröße festgelegt. In diesem Aspekt verhält sich Ma‐
ya/Arnold gradliniger. Um ein Baking zu starten, wird lediglich die Auswahl eines Shape‐Objekts
verlangt. Im zugehörigen Kontextmenü können die Bild‐Dimensionen frei gewählt werden.
Maya/Arnold ermöglicht die Manipulation aller vorhandenen Parameter über das Render‐
To‐Texture Kontextmenü. Dazu zählen wie bereits genannt Bild‐Dimensionen und Ausgabepfad,
aber auch die Anzahl der Rendersamples und die Nutzung bestimmter Bildfilter. Bei Blender
werden die Samples für das Rendering global festgelegt und müssen über mehrere Renderings
hinweg nicht mehr angepasst werden.
Beide Baking‐Vorgänge rendern bei unveränderten Einstellungen die Oberfläche des Ob‐
jekts mit allen Materialeigenschaften des Shaders und Lichteinflüssen der Szene. Blender er‐
204.1. Ist‐Zustand
Tabelle 4.2: Begriffslegende
Ziel‐Bild: Das Bild auf dem die Map‐Informationen gerendert wer‐
den sollen.
Quell‐Node: Die Node, deren Output auf das Ziel‐Bild gebaked werden
soll. Dies kann jede Node im Material sein, unabhängig wie
viele Nodes ihr vorgeschaltet sind.
Emission‐Shader (Blender) / Diese Shader geben die in ihnen ankommenden In‐
Flat‐Shader (Maya): formationen als lokale Lichtquelle aus. Dies bedeutet,
dass Flat/Emission‐Materialen ohne Einfluss anderer Licht‐
quellen sichtbar in der Szene sind. Gleichzeitig ignorie‐
ren Emission‐Materialien eingehendes Licht. Durch die‐
se Eigenschaften sind sie ideal dazu geeignet, Rohdaten
von Shading‐Nodes darzustellen. Sie sind bei Entwicklern
sehr beliebt beim Entwickeln und Debuggen von Shader‐
Netzwerken.
Material Output (Blender) / Der Material Ouput/die Shading Engine ist die letzte Node
Shading Engine (Maya): eines Node‐Trees. Was in dieser Node ankommt, wird als
Material am Objekt in der Szene/im Rendering dargestellt.
möglicht von Haus aus verschiedene Maps zu berechnen, benötigt aber für jede Einzelne das
Erstellen eines neuen Bildes und die manuelle Durchführung. Außerdem sind für Metalness‐
Bakings keine Optionen verfügbar. Die Baking‐Funktion erlaubt zwar als Option „Glossyn‐
ess“, diese rendert aber nur die Specular‐Anteile des Shaders. Entwickler, die den Metalness‐
Workflow nutzen, haben hier keine Option eine Metalness‐Map zu baken.
Maya/Arnold erlaubt standardmäßig nur Kombinationsrenderings mit Render‐To‐Texture.
Um einzelne Parameter des Shaders zu baken, bedarf es zusätzlicher Arbeit im Hypershade.
Maya/Arnold exportiert die Renderings automatisch in das gewählte Zielverzeichnis, ex‐
portiert allerdings nur exr‐Dateien. Nutzer, die das Bildformat ändern möchten, müssen dies
über weitere Programme realisieren. Blender exportiert Bilder nicht nach Beenden des Baking‐
Vorgangs und bietet auch keine automatisierte Option dazu. Bilder werden in der Szene gespei‐
chert und müssen einzeln exportiert werden, wobei aber ein beliebiges Dateiformat angegeben
werden kann, sowie einige andere gängige Bildparameter.
Die im Folgenden vorgestellten Workflows beziehen sich auf das Rendern der Outputs ein‐
zelner Nodes und Shader‐Werte, um PBR‐Maps zu erstellen. Es wird vorausgesetzt, dass alle
Modelling‐, UV‐ und Shading‐Arbeiten abgeschlossen wurden und die PBR‐Materialen nur noch
gerendert und exportiert werden müssen.
Erste Unterschiede sind bereits in der Vorbereitung erkennbar. Blender nutzt für seine
Baking‐Funktion die global eingestellten Sample‐Werte von Cycles. Dadurch muss in der Praxis
dieser Wert nur einmal im Voraus bestimmt werden. Maya/Arnold Render‐To‐Texture gibt ei‐
nen Default‐Wert vor, der vor jedem Baking angepasst werden muss. Dafür befinden sich alle
für den Nutzer und den Renderprozess wichtigen Parameter im selben Kontextfenster.
21Sie können auch lesen
