3D-Render-Pipeline für Produktkonfiguratoren
Am Beispiel einer Uhr: 256 Kombinationen aus 17 Renderings, unter einem Megabyte Ladegewicht. Für ein anderes Produkt ändern sich die Blender-Datei und eine Konfiguration — nicht die Logik.
Zum Konfigurator →Ziel
Produktkonfiguratoren stehen meist vor derselben Wahl: entweder eine 3D-Engine im Browser, die schnell reagiert, aber nie aussieht wie ein Produktfoto — oder gerenderte Bilder, die gut aussehen, aber in der Menge nicht beherrschbar sind.
Ich wollte den dritten Weg bauen: echte Cycles-Renderings, die sich erst im Browser zusammensetzen. Und zwar nicht als einmaliges Projekt, sondern als Ablauf, der sich auf beliebige Produkte anwenden lässt. Die Uhr war der Testfall, an dem sich das beweisen musste.
Das Rechenproblem
Vier Bauteile mit je vier Farben ergeben 256 Kombinationen. Jede einzeln zu rendern ist der naheliegende Weg und gleichzeitig der falsche: 256 Bilder pro Perspektive, bei drei Perspektiven 768. Jede zusätzliche Farbe potenziert den Aufwand, statt ihn zu erweitern.
Das Prinzip: Ebenen statt Kombinationen
Jedes Bauteil wird einzeln vor transparentem Hintergrund gerendert. Vier Bauteile mal vier Farben plus eine Aufnahme der Szene ergeben 17 Bilder — nicht 256. Im Browser liegen sie deckungsgleich übereinander, ein Farbwechsel blendet eine Ebene aus und eine andere ein.
Der Aufwand wächst additiv statt exponentiell. Eine fünfte Farbe kostet vier zusätzliche Renderings, keine 369. Ein fünftes Bauteil kostet vier weitere. Damit skaliert der Ansatz auch für Produkte, die deutlich mehr Varianten haben als eine Uhr.
Die Pipeline
1 — Renderskript (Python/Blender). Liest die Bauteile aus einer Konfiguration, erkennt Kameras über eine Namenskonvention und behandelt jedes übrige Objekt automatisch als Umgebung. Weist die Materialien nacheinander zu, rendert und schreibt die Dateien nach einem Namensschema, das exakt den Bildpfaden im Frontend entspricht.
2 — Konvertierung. Ein zweites Skript wandelt die PNG-Masters in WebP um, wahlweise für alle oder einzelne Perspektiven. Blender übernimmt das selbst, es braucht also keine zusätzlich installierten Werkzeuge.
3 — Frontend. Eine einzelne HTML-Datei ohne Framework und ohne Abhängigkeiten. Alle Ebenen liegen von Beginn an im DOM, der Wechsel ist ein reiner Opacity-Übergang — kein Nachladen, kein Flackern beim Klick.
CAM_. Mehr Konvention braucht es nicht.Automatisierung
Der gesamte Renderprozess ist ein Befehl:
blender -b uhr.blend -P render_layers.py
Kein geöffnetes Fenster, kein manueller Export, kein Zwischenschritt. Das Skript geht jede Kamera durch, in jeder Kamera jedes Bauteil, in jedem Bauteil jede Farbe — weist Materialien zu, setzt Holdout, rendert, benennt die Datei und stellt am Ende den Ausgangszustand der Szene wieder her.
Vorab prüfen. Bevor das erste Bild gerendert wird, kontrolliert das Skript, ob alle Objekte, Materialien und Kameras vorhanden sind. Fehlt etwas, bricht es sofort ab und nennt den fehlenden Namen. Ein Tippfehler kostet damit Sekunden statt einer Stunde Renderzeit.
Teilweise wiederholen. Über ein Argument lässt sich eine einzelne Perspektive neu rendern, statt alle 51 Bilder. Als ich eine Kamera nachträglich neu ausgerichtet habe, waren das drei Minuten statt acht — und die übrigen Bilder blieben unangetastet.
Reproduzierbar bleiben. Derselbe Befehl erzeugt dieselben 51 Dateien unter denselben Namen. Eine geänderte Farbe bedeutet: Material anpassen, Befehl ausführen, fertig. Es gibt keinen Schritt, den man vergessen kann, und keine Datei, die versehentlich aus einem älteren Durchlauf stammt.
Das Namensschema ist dabei die Klammer zwischen den Stufen. Die Datei gehaeuse__rot.webp entsteht aus dem Bauteil Gehäuse mit dem Material M_Gehaeuse_Rot und wird im Frontend über genau diesen Pfad geladen. Blender, Konvertierung und Website müssen sich nicht abstimmen — sie folgen derselben Regel.
Zwei Details, an denen es sonst scheitert
Verdeckung. Beim Rendern eines Bauteils werden alle anderen auf Holdout gesetzt. Sie verschwinden für die Kamera, verdecken einander aber weiterhin korrekt und werfen weiterhin Schatten. Ohne das erscheint ein Armband, das hinter dem Gehäuse liegt, im gestapelten Bild davor.
Neutrale Nachbarn. Während ein Bauteil gerendert wird, tragen alle übrigen ein neutrales Graumaterial. Sonst färbt ein rotes Gehäuse das Licht, das auf das Armband fällt — und diese Ebene passt anschliessend nur noch zu genau dieser einen Gehäusefarbe.
Beides fällt im Einzelbild nicht auf. Erst im Stapel wird sichtbar, dass es nicht zusammenpasst.
Was produktspezifisch ist — und was nicht
| Bleibt gleich | Ändert sich pro Produkt |
|---|---|
| Renderskript | Blender-Datei |
| Konvertierung | Bauteil- und Farbliste |
| Ebenenlogik im Frontend | Beschriftungen |
| Namensschema der Dateien | Kamerapositionen |
| Aufbau der Konfiguration | Gestaltung |
Für Möbel, Fahrräder oder Carports wird kein Code angefasst. Es wird eine neue Szene gebaut und eine Liste ausgetauscht.
Der Testfall
Die Uhr besteht aus Armband, Schnalle, Gehäuse und Zeigern in je vier Farben — Bandit Blue, Princess Pink, White Widow und Sizzler Red. Dazu drei Perspektiven: Totale, Schnallendetail und Makro.
Die Oberfläche ist in Dark Mode gehalten, mit einem Bedienfeld aus mattiertem Glas über dem Rendering. Die Perspektiven liegen als Vorschaubilder am Rand und aktualisieren sich live mit der gewählten Konfiguration. Jede Konfiguration hat eine eigene URL und ist damit teilbar — die Grundlage für eine spätere Anfrage- oder Bestellfunktion.
| Bauteile / Farben | 4 × 4 |
| Kombinationen | 256 |
| Renderings | 51 (17 pro Perspektive) |
| Renderzeit | ca. 8 Minuten |
| PNG → WebP | 11,3 MB → 0,3 MB pro Perspektive |
| Gesamtgewicht der Seite | rund 1 MB |
KI im Prozess
Ich habe Claude nicht als Codegenerator eingesetzt, sondern als zweite Hand in Blender und als Prüfinstanz vor teuren Schritten. Über eine MCP-Verbindung hatte das Modell direkten Zugriff auf meine Szene — auslesen, prüfen, verändern.
Prüfen statt raten. Vor jedem Renderdurchlauf wurde die Datei kontrolliert: fehlende Kamera, fehlende Materialien, doppelte Datenblöcke, falsche Dateipfade. In einem Fall habe ich die Ausrichtung aller drei Kameras rechnerisch prüfen lassen, bevor 51 Renderings starteten. Eine Kamera zeigte am Objekt vorbei. Aufgefallen wäre das erst nach dem Durchlauf.
Mechanisches delegieren. 17 Materialien anlegen, benennen, mit passenden Metallic- und Roughness-Werten versehen und gegen automatisches Löschen sichern: zwanzig Minuten Klickarbeit oder zwei Sekunden Skript. Die Farbwerte wurden dabei aus meinen eigenen Materialien ausgelesen, statt sie neu zu schätzen.
Entscheidungen behalten. Kameraführung, Szenenaufbau, Farbnamen und gestalterische Richtung kamen von mir. Die ersten drei Designvorschläge habe ich verworfen, weil sie beliebig waren — erst die konkrete Vorgabe «Apple Dark Mode, mattiertes Glas» führte zum Ergebnis. Auch bei den Farbnamen kam der Ansatz von mir, die Varianten aus dem Dialog.
Geschrieben wurde dabei viel: das Renderskript samt Holdout-Logik und Kameraerkennung, die WebP-Konvertierung und das komplette Frontend. Dazu kam, dass Code, Kontrolle der Szene und Fehlersuche in derselben Schleife stattfanden — auffallen, prüfen, korrigieren und weiter, ohne das Werkzeug zu wechseln.