86 lines
9.9 KiB
Markdown
86 lines
9.9 KiB
Markdown
Während der Implementierung der ViewLayers ist aufgefallen, dass die Zeit, die es dauert ein Bild und die Segmentierungsmasken zu rendern, gesunken ist im Vergleich zur Ausgangslage des Projekts. Um dieses Beobachtung zu validieren und deren Ursache zu finden wurde das folgende Experiment durchgeführt.
|
|
|
|
Ein Durchlauf des Scripts erzeugt eine definierte Anzahl an Bildern und den dazugehörigen Segmentierungsmasken.
|
|
|
|
Listing ... zeigt als Pseudo-Code den Groben Ablauf des Scripts. Anfangs wird einmalig die Konfiguration sowie geladen. Diese definiert einerseits die Wertebereiche für die später zufällig gewählten Parameter wie z. B. die möglichen Grauwerte für Haut, Sclera, Iris usw. Dort wird auch definiert, wie viele Bilder generiert werden sollen. Darauf folgt eine Schleife, die so viele Iterationen hat, wie Bilder generiert werden sollen (X). Für jede dieser Iterationen wird dann die zufällige Konfiguration bestimmt, also die Blickrichtung des Auges, die Grauwerte der Objekte in der Szene, wie weit das Augenlid geöffnet ist. Mit diesen Werten werden dann die Objekte in den Szenen modifiziert. Es werden auch Node-Trees für die Materialen und das Compositing neu erzeugt. Nachdem die Konfiguration abgeschlossen ist, wird das Bild und dessen Segmentierungsmasken gerendert.
|
|
|
|
```
|
|
1. Initialiserung
|
|
2. Wiederhole x mal
|
|
3. Modifiziere Blender-Szene mit zufälliger Konfiguration
|
|
4. Rendere ein Bild und Segmentierungsmasken
|
|
```
|
|
Daraus ergeben sich mehrere Punkte, an denen die Laufzeit verbessert worden sein kann:
|
|
|
|
Da in der im Rahmen dieser Arbeit erweiterten Implementierung nur eine Szene existiert und in der Initialisierung für alle Szenen Logik ausgeführt wird, kann die Initialisierungszeit verkürzt sein. Da diese allerdings nur einmalig ausgeführt wird, kann sie höchstens Einfluss auf die Gesamtlaufzeit haben. Allerdings wurden Verbesserungen in der Render-Zeit einzelner Bilder beobachtet, somit müssen diese signifikanten Verbesserungen in der Schleife auftreten.
|
|
|
|
Der nächste mögliche Aspekt ist die Zeit, die für die Konfiguration der Szene nötig ist. In diesem Teil des Scripts wurden große Änderungen vorgenommen, da durch den Umstieg auf ViewLayer Objekte nur noch einmalig und nicht in mehreren Szenen angepasst werden müssen. Allerdings sind nun auch deutlich mehr zufällig gewählte Variablen vorhanden, was die Laufzeit dieses Schritts verlängern könnte.
|
|
|
|
Zuletzt müssen die Bilder gerendert werden. Das ist mit Abstand der aufwendigste Teil dieses Prozesses, der demensprechend die meiste Laufzeit in Anspruch nimmt. Daher ist auch zu erwarten, dass die Laufzeitverbesserungen in diesen Schritt entstehen. Sie können entweder durch den Wechsel von mehreren Szenen auf die ViewLayer entstanden sein, oder durch den Wechsel von Blender-Version 4.x auf die zum Zeitpunkt dieser Arbeit neueste Version 5.0.
|
|
|
|
Unter diesen Gesichtspunkten ergeben sich folgende Laufzeiten die direkt gemessen werden können:
|
|
- Initialisierungszeit ($t_{init}$):
|
|
Wie lange dauert der Initialisierungsschritt. Aufgrund der geringen Arbeit, die in diesem Schritt passiert ist besten Falls eine minimale Verringerung der Laufzeit zu erwarten.
|
|
- Zeit für die zufällige Konfiguration der Szene ($t_{config}$):
|
|
Die Zeit, die es dauert die Szene mit zufälligen Parametern für ein einzelnes Bild zu modifizieren. Es ist eine moderate Verbesserung der Laufzeit zu erwarten, da das Verändern der Iris-Geometrie nur noch einmal durchgeführt wird, statt wie vorher dreimal. Generell entfallen Szenen-Wechsel. Es wird kaum mehr Laufzeit erwartet durch das setzen der zufälligen Gewichte für die Blend-Shapes wie die Schließung des Augenlids und der anderen Veränderungen an der Periorbital-Geometrie, sodass insgesamt eine Verbesserung zu beobachten sein dürfte.
|
|
- Zeit für das Rendern der Szene ($t_{render}$):
|
|
Die Zeit, die es dauert vom Befehl das Bild und die Masken zu rendern, bis dieses Fertig gerendert ist. Da dies der aufwändigste Schritt ist, wird hier die meiste Verbesserung erwartet.
|
|
- Gesamtlaufzeit eines Bildes ($t_{frame}$):
|
|
Dies ist die Laufzeit einer Iteration der Schleife, also die zufällige Konfiguration der Szene plus die Render-Zeit. Mathematisch ist also $t_{frame} = t_{config} + t_{render}$ zu erwarten
|
|
- Gesamtlaufzeit des Scripts ($t_{script}$):
|
|
Die Gesamtlaufzeit innerhalb des Scripts. Hier spielen also die einmalige Laufzeiten wie z. B. die Initialisierung eine Rolle, aber insbesondere die Laufzeit der $x$ Iterationen in denen die Bilder generiert werden. Mathematisch ist also $t_{script} = t_{init} + \sum_{i = 0}^{x}t_{image,i}$ oder wenn man berücksichtigt, dass die Laufzeit $t_{image}$ pro Bild nach einer Aufwärmphase innerhalb einer Standardabweichung konstant sein sollte $t_{script} \approx t_{init} + x \cdot t_{image}$ zu erwarten.
|
|
- Gesamtlaufzeit des Befehls ($t_{total}$)
|
|
Zu Ausführen des Scripts wird per Kommandozeile Blender als Head-Less Instanz, also ohne sichtbares Fenster, gestartet. Dabei bekommt es sowohl den Pfad zur zu ladende Szene sowie zum auszuführenden Script übergeben. Diese ist für unsere Betrachtung keine sonderlich relevanten Informationen, da lediglich die einmalige Startzeit (und Stoppzeit) von Blender zusätzlich gemessen wird. Da dies allerdings einfach zu messen ist wird es der wissenschaftlichen Vollständigkeit zusätzlich erfasst. Mathematisch kann folgende Laufzeit erwartet werden: $t_{total} = t_{startup} + t_{script} + t_{shutdown}$.
|
|
|
|
|
|
Es ist zu erwarten, dass die Laufzeiten der Iterationen einer Aufwärmphase unterliegen, in der anfangs Iterationen relativ lange dauern und kürzer werden, bevor sie sich relativ zuverlässig um eine Asymptote sammeln. Daher müssen ausreichend viele Iterationen durchgeführt werden um einerseits die Aufwärmphase zu überwinden und dann ausreichend Datenpunkte für die Bestimmung von Mittelwert und Standardabweichung zu sammeln.
|
|
In vorläufigen Tests wurde festgestellt, dass die Aufwärmphase nach etwa 10 Iterationen zuverlässig überwunden ist und die Laufzeit der Iterationen dann relativ stabil ist. Es wurde 120 als Anzahl der Iterationen, also der zu generierenden Bilder, gewählt. Das sollten genügend Iterationen sein, um zuverlässige Mittelwerte und Standardabweichungen unter Ausschluss der Aufwärmphase zu liefern.
|
|
|
|
Es wurden fünf Durchläufe durchgeführt, um einerseits mehrere Messwerte für die einmaligen Messwerte wie Initialisierungszeit und Gesamtlaufzeit zu sammeln. Außerdem erlaubt dies unerwartete Auswirkungen die Generierungszeit auszuschließen.
|
|
|
|
# Testdurchläufe:
|
|
Es werden grundsätzlich zwei Versionen von HEyes mit einander verglichen: Die original Implementierung von HEyes, auf der die vorliegende Arbeit aufbaut, und die fertige Implementierung dieser Arbeit mit allen zusätzlichen Funktionalitäten. Dabei ist anzumerken, dass die original Implementierung so angepasst wurde, dass die Messung alle nötigen Laufzeiten möglich ist.
|
|
|
|
1. Og Implementierung + Blender 4.5:
|
|
Die praktisch unveränderte Implementierung wird mit der alten Blender Version getestet. Einzig um sicherzustellen, dass die Ergebnisse reproduzierbar sind, wurde wie in Abschnitt ... beschrieben die Möglichkeit implementiert, die Zufallsgeneratoren mit einem festen Seed-Wert zu initialisieren. Die hierdurch gewonnenen Messwerte stellen die Baseline-Laufzeit dar, anhand welcher Verbesserungen in nachfolgenden Experimenten erkannt werden können.
|
|
2. Og Implementierung + Blender 5.0:
|
|
Die Implementierung aus Test 1 wurde minimal angepasst, um mit der API der von Blender 5.0 kompatibel zu sein. Alle anderen Aspekte bleiben Unverändert. Dadurch werden die Performance-Veränderungen, die durch die Blender Version verursacht werden sichtbar gemacht.
|
|
3. Neue Implementierung + Blender 4.5:
|
|
Die neue Implementierung wurde wieder mit Blender 4.5 kompatibel gemacht und getestet. Das erlaubt zusätzlich den Vergleich, ob die Änderungen in der Implementierung in verschiedenen Blender-Versionen ggf. effizienter wurden.
|
|
4. Neue Implementierung + Blender 5.0:
|
|
Dies stellt die endgültige Version der neuen Implementierung und somit die endgültige Performance dar.
|
|
|
|
Um die zusätzlichen Messwerte erfassen zu können, musste das Script angepasst werden. Um sicherzustellen, dass die Messung minimalen Einfluss auf die Laufzeiten hatte, wurde zusätzlich der Test ... auch ohne Instrumentalisierung durchgeführt und nur die Gesamtlaufzeit erfasst. Wenn die Ergebnisse zeigen, dass die Gesamtlaufzeiten innerhalb der Standardabweichung praktisch gleich sind, kann davon ausgegangen werden, dass die Instrumentalisierung des Codes keinen Einfluss auf die Gesamtlaufzeit sowie die Teillaufzeiten hatte.
|
|
|
|
> [!question]- TODO, falls ich Bock habe
|
|
> Zusätzlich wurde die Konfiguration aus Test 4 mit unterschiedlichen Blender-Einstellungen getestet:
|
|
>
|
|
>
|
|
>
|
|
> | Parameter | |
|
|
> | ----------- | --------------------- |
|
|
> | Compositing | 1. CPU<br>2. GPU |
|
|
> | Rendering | 1. CPU<br>2. GPU |
|
|
> | Renderer | 1. Eevee<br>2. Cycles |
|
|
>Das wären 35 weitere Tests (eigentlich 36, aber die Standard-Config ist CPU Comp, GPU Eevee Render)
|
|
|
|
Bereits im Laufe der Vorbereitung dieses Experiments fiel auf, dass die Vorbereitung der Szene für das Generieren eines Bildes deutlich mehr Zeit in Anspruch nimmt, als zunächst angenommen wurde. Daher wurde dieser zunächst vernachlässigte Schritt genauer untersucht.
|
|
|
|
Variablen:
|
|
Blender: 4.5 vs 5.0
|
|
Code: Alt vs Neu
|
|
Cache Luminance (lum): Yes vs No
|
|
Optimized Texture Generation (optitex): Yes vs No
|
|
|
|
|
|
Tests:
|
|
1. Alt mit 4.5
|
|
2. Alt mit 5.0
|
|
3. Neu mit 4.5, lum und Optitex aus
|
|
4. Neu mit 5.0, lum und Optitex aus
|
|
-> betrachtet isoliert Performanceverbesserungen durch Blender 5
|
|
5. Neu mit 5.0, lum und Optitex an
|
|
-> blender 5, lum und optitex sind orthogonal zueinander, daher gleichzeitig messbar und tortzdem individuell vergleichbar. Betrachtet isoliert die Optimierung, auch auf alt Anwendbar
|
|
|
|
-> Wenn ich für _Experiment 2_ Bilder erzeuge, dann kann ich das ggf. mit Blender 5, lum und optitex machen
|