1. Projektstruktur 1. (Wie ist das Repository aufgebaut) 2. Ablauf der bestehenden Pipeline? 3. Allgemeine Änderungen an den bestehenden Scripts: 1. Upgrade auf Blender 5 - Eigentlich nur eine Änderung nötig: im Blender Compositing-Graph ist pro Output-Textur eine Output-Node nötig (statt vorher einer Node für alle) 2. unwichtige Änderung: konsequente Type-Annotations im gesamten Projekt 3. Möglichkeit einen bestimmten Seed in Config-Datei einzutragen 4. Möglichkeit, dass die modifizierte Szene abgespeichert wird (für Debugging) 4. Umbau der Pipeline 1. Augenlid mit Shape-Key implementieren 1. Probleme mit dem alten Ansatz - Hat ein getrennten Modell für Augenlid - -> Kann nicht vollständig geschlossen werden - -> passt sich nicht an Auge / periorbitale Haut an 2. Lösung: Modell weg -> mit Shape-Key umsetzen - Script muss angepasst werden um statt objekt-Rotation festzulegen den Shape-Key zu steuern - Vorteile: - Erlaubt es das Auge vollständig zu schließen - Mit Wrap-Modifier an das Auge angeschmiegt 2. Problem: Augenlid-Segmentierungsmaske funktioniert jetzt nicht mehr mit Cryptomattes 1. erster Versuch: Kompliziert Gewichte für Augenlid-Vertex-Group mit GEometry Nodes an Haut-Shader reichen und mit extra Shader-Output ausgeben - Umständlich und unpräzise (sind an Geometrie-Detail gebunden) 2. bessere Lösung: Verwenden eine zweite Haut-Textur, in der Pixel des Augenlids weiß und der Rest schwarz ist - Vorteil: Viel einfacher, kann direkt mit Texturkoordinate im Haut-Shader ausgelesen und direkt an den extra Shader-Output übergeben werden 3. Wimpern und Augenbrauen 1. Probleme mit dem alten Ansatz - War vorher feste Geometrie -> kann nicht an Shapekeys angepasst werden 2. erster Versuch mit Hair-Particles - funktioniert nicht gut -> Die Wimpern gehen kaputt, wenn man das Augenlid bewegt 3. zweiter Versuch mit Hair-Modifier (gut) - funktioniert deutlich besser - aber nicht perfekt - Ansätze für zukünftige Verbesserung anreißen (z. B. Variation in Länge/Dicke und Winkel durch Geometrie Nodes möglich) 4. Periorbitalregion 1. Umsetzung mit Shape-Keys - TODO: Es so klingen lassen, als hätte ich das nicht in zwei Stunden hingeklatscht - TODO: Irgendwie klar machen, dass die absolut keiner medizinischen Grundlage folgen, sondern einfach nach Gefühl gebastelt sind 😅 2. Problem: Bestimmte Kombinationen von Shape-Keys kollidieren, weil sie doch nicht quasi-Orthogonal sind (z. B. kollidieren einige mit dem geschlossenen Augenlid) - Lösung: Korrektur-Shape-Keys mit Driver ansteuern 3. Änderung an Script: - Konfiguration: In Json-Config kann einfach für jeden Shape-Key den man steuern möchte der Name des Keys mit min- und max-Wert eingetragen werden - Anwendung: Für alle in der Json eingetragenen Shape-Keys wird automatisch ein zufälliger Wert innerhalb der konfigurierten Range gezogen und für den Shapekey angewendet. 5. Implementierung für die Tests: 1. Experiment 1.1: Performance Benchmarks 1. (wahrscheinlich nicht so interessant): Zeit wird mit time.perf_counter_ns() gemessen und als CSV-Datei gespeichert 2. Benchmark-Runner-Script: 1. In Config-Json kann eingetragen werden: - Welche Benchmarks laufen. Für jeden Benchmark: - Name, - Git-Commit im Repo - Ob mit Blender 4 oder 5 ausgeführt werden muss - Wie viele (X) Bilder pro Durchlauf - Wie viele (Y) Durchläufe - Output-Verzeichnis 2. Benchmark Runner macht dann für jeden konfigurierten Benchmark: 1. in einem Git-Worktree das Repo mit dem jeweiligen Commit auschecken 2. Passt config im Worktree an, sodass X viele Bilder generiert werden und diese als Unterordner im konfigurierten Benchmark-Output landen 3. Führt Y Durchläufe durch 3. Auswertung mit Jupyter Notebook 2. Experiment 1.2: Detaillierte Performance Auswertung - ??? wie viel hiervon in der Methodik? - zusätzlich erfasste Werte - ggf. für das eine Ding Mikrobenchmarks - konkrete Änderungen - Haut-Luminanzwerte und Compositing-Graph cachen - Anpassung an Sklera-Generierung nach den Mikrobenchmarks - Das ist sehr technisch und der Effekt am Ende praktisch irrelevant 3. Experiment 2: Yolo Training 1. 500k-Datenextraktor? Oder reicht es, dass in Methodik beschrieben ist, wie die Daten extrahiert wurden 2. Verbesserungen/Änderungen an LEyes Parameter Picker (nur ein bisschen, nicht zu sehr ins Detail gehen) 1. Output Median percentiles 5, 10, 90 and 95 2. Fixed metrics changing when switching to different image 3. Add mask overlay controls for alpha transparency and bounding box display 4. Add dirty-state and ask for confirmation on image change 5. Don't continuously Refresh stats while drawing, only on release 6. Add deadzone functionality with adjustable borders Was mir gerade noch zur Implementierung eingefallen ist: Es gab einen Umbau der Blender-Datei von drei Szenen auf eine Szene mit drei Viewlayers. Ich habe noch etwas, das irgendwie in der Arbeit einsortiert werden muss: Der erste Performance benchmark hat veranlasst, dass die versuchete die Performance weiter zu verbessern. Dementsprechend wurde der zweite detailliertere Benchmark gemacht, dann Optimiert, dann nochmal Benchmark für vorher nacher vergleich der optimierung. Wie soll ich das einordnen. Die Finalen Ergebnisse sind klar, die gehören ins Auswertungskapitel, aber der vorherige Detaillierte benchmark um zu entscheiden, was optimiert werden soll. Ist das ein eigener Abschnitt/Kapitel oder so? Ich habe jetzt gerade eine Rohschrift (unfertig) in "@MasterLatex/content/0X_PerformanceVerbesserung.tex". Das muss irgendwie einsortiert werden. Ich Grunde möchte ich eine gute Struktur haben, was kommt in Methodik, was kommt in Versuchsplanung (und Versuchsauswertungsplanung), was ist Implementierung. Wie soll ich diese Kapitel strukturieren.