Virtual Try-On: vom Produktfoto zur Live-Anprobe

Ein Virtual Try-On, das auf den bereits vorhandenen Katalogbildern aufsetzt: kein eigenes Fotoshooting, keine manuelle 3D-Modellierung, keine App zum Installieren.

Der Kontext

Eine Partner-Web-Agentur von Rayo Consulting wollte einen Virtual-Try-On-Dienst aufbauen, um ihn ihren eigenen Mode-E-Commerce-Kunden anzubieten. Der geschäftliche Bedarf war klar: Bei einem Kleidungsstück will der Kunde vor dem Kauf sehen, wie es ihm steht, und eine Bildergalerie am Model reicht nicht aus, um diese Unsicherheit zu nehmen.

Die Rahmenbedingung war ebenso klar. Damit der Dienst verkäuflich ist, musste er mit den Katalogen so funktionieren, wie sie bereits vorliegen: Kein Kunde der Agentur würde das gesamte Sortiment neu fotografieren oder 3D-Modellierung Referenz für Referenz beauftragen. Ein Dienst, der eine solche Anfangsinvestition verlangt, verkauft sich nicht.

Unsere Aufgabe war damit zuerst eine ingenieurtechnische und erst danach eine technologische: die Grenzkosten jedes neuen Kleidungsstücks so weit zu senken, dass sie ein wiederholbares Geschäftsmodell tragen.

Das Problem der 3D-Pipeline

Ein Virtual Try-On braucht für jedes Produkt ein 3D-Asset. Die klassischen Wege sind zwei, und beide sind teuer.

Der erste: manuelle Modellierung. Ein 3D-Artist baut jede Referenz nach. Hohe Qualität, aber Aufwand und Kosten, die bei einem Katalog mit Hunderten Artikeln nicht skalieren, und jede neue Kollektion beginnt von vorn.

Der zweite: fotogrammetrisches Scannen. Erfordert eigene Ausrüstung und den physischen Zugriff auf das Produkt, oft genau dann, wenn es bereits im Lager liegt oder noch gar nicht eingetroffen ist.

Keiner der beiden Wege konnte einen produktisierten Dienst tragen, weil beide dem Endkunden Kosten aufbürden, die linear mit dem Katalog wachsen. Das einzige Asset, das in jedem E-Commerce für jedes Produkt garantiert vorliegt, sind die Katalogbilder: Dort musste die Pipeline ansetzen.

Die Konvertierung mit Tripo3D

Wir haben die Pipeline um Tripo3D herum gebaut, das aus den bereits im Katalog vorhandenen Produktbildern ein texturiertes 3D-Mesh erzeugt.

Damit verschieben sich die Grenzkosten jeder neuen Referenz von „Stunden Arbeit eines 3D-Artists" zu „einem Aufruf der Pipeline", und genau das macht den Dienst wiederkehrend verkäuflich. Die Bilder, die ohnehin auf der Produktseite liegen, werden zum Input des Try-On, ohne dem Prozess des Endkunden Schritte hinzuzufügen.

Die erzeugten Meshes durchlaufen anschließend eine Normalisierungsphase, denn ein automatisch generiertes Asset kommt weder am Bezugssystem des Renderers ausgerichtet noch leicht genug für den Browser an. Die Pipeline führt nacheinander aus:

• Neuausrichtung: Die Vertikalachse des Kleidungsstücks wird auf die Y-Achse der Welt gelegt und der Ursprung auf den Ankerpunkt (die Schulterlinie) verschoben, sodass dieselbe Transformation für alle Referenzen gilt.
• Dezimierung: von ~180k Dreiecken aus Tripo3D auf ~12k, unter Erhalt der Silhouette und der Ärmeltopologie, jener Bereiche, in denen der Fehler bei Bewegung am stärksten auffällt.
• Texture-Baking: Die erzeugten Maps werden in einen 2K-PBR-Atlas (Albedo, Normal, Roughness) zusammengefasst, um pro Kleidungsstück bei einem einzigen Draw Call zu bleiben.
• Komprimierung: Export nach glTF mit Draco für die Geometrie und KTX2/Basis für die Texturen, sodass die Nutzlast pro Referenz im Bereich von Hunderten kB statt Megabyte bleibt.

Diese Phase ist vollständig automatisiert: Eine neue Referenz geht als Katalogbilder hinein und kommt als Try-On-fertiges Asset heraus, ohne manuelle Schritte.

Das Tracking: erweitertes MediaPipe

Das Echtzeit-Tracking basiert auf MediaPipe und läuft vollständig im Browser des Nutzers: Kein Videoframe wird an einen Server gesendet, was das Datenschutzbild gegenüber einer serverseitigen Lösung erheblich vereinfacht.

MediaPipe allein war für die Verankerung des Kleidungsstücks jedoch nicht präzise genug. Das Standard-Pose-Modell erfasst das Skelett mit wenigen Schlüsselpunkten (Schultern, Ellbogen, Handgelenke, Hüften), optimiert auf allgemeine Robustheit, nicht auf Subpixel-Stabilität an den Punkten, auf denen ein Kleidungsstück aufliegen muss. Kleine Schwankungen der Landmarks führen dazu, dass das Kleidungsstück auf dem Körper „schwebt", statt ruhig zu sitzen.

Deshalb haben wir eigene Erweiterungen des Landmark-Sets entwickelt. Aus den 33 nativen Punkten leiten wir 8 weitere ab (Schultermitte, Halsansatz, Brustbeinpunkt, Torso- und Taillenachse), gewonnen durch beschränkte Interpolation statt durch direkte Inferenz, was sie stabiler macht als die Punkte, aus denen sie entstehen.

Über diesen Punkten läuft ein One-Euro-Filter mit adaptivem Cutoff: aggressiv beim Glätten, wenn der Nutzer stillsteht, permissiv bei schnellen Bewegungen. Das ist der Unterschied zwischen einem Kleidungsstück, das im Stand zittert, und einem, das bei schnellen Bewegungen hinterherhinkt: Ein Filter mit festem Cutoff zwingt zur Wahl zwischen beidem.

Die Skalierung des Kleidungsstücks wird nicht aus einem einzelnen Segment abgeleitet, sondern aus einer über mehrere Landmark-Abstände gemittelten, ausreißerrobusten Körperschätzung. Ein einzelnes Frame, in dem MediaPipe ein Handgelenk falsch setzt, lässt das Kleidungsstück nicht mehr „pulsieren".

Das Rendering: Three.js

Die Rendering-Schicht ist Three.js: Sie setzt das Mesh des Kleidungsstücks über den Webcam-Feed und aktualisiert es in jedem Frame entlang der getrackten Landmarks, wobei die Skalierung an die erkannte Statur angepasst wird.

Die Arbeit lag hier vor allem bei visueller Kohärenz und Budget. Zum Ersten: eine aus dem Webcam-Feed geschätzte und auf das Mesh angewandte Beleuchtung, damit ein helles Kleidungsstück in einem dunklen Raum nicht unnatürlich hell wirkt; Verdeckungen über eine Segmentierungsmaske, sodass das Kleidungsstück hinter den Armen verschwindet, wenn der Nutzer sie verschränkt.

Zum Zweiten: Bei 30 FPS beträgt das Frame-Budget 33 ms, und darin müssen Landmark-Inferenz, Filterung, Skelett-Update und Draw Calls Platz finden. Wir haben die beiden Lasten getrennt: Die MediaPipe-Inferenz läuft in einem Web Worker mit WebGL-Backend, das Rendering bleibt im Main Thread. So erzeugt eine Latenzspitze der Inferenz keine verworfenen Frames im Rendering, sondern nur ein etwas älteres Pose-Update. Wahrnehmbar ist das deutlich weniger.

Das Ergebnis ist eine Ende-zu-Ende-Latenz unter 40 ms vom aufgenommenen Frame bis zum zusammengesetzten Kleidungsstück: unterhalb der Schwelle, ab der sich die Bewegung vom eigenen Körper entkoppelt anfühlt.

Technologie-Stack

Bereich	Technologien
3D-Generierung	Tripo3D (Katalogbilder → texturiertes Mesh)
Mesh-Nachbearbeitung	Dezimierung auf ~12k Tri, 2K-PBR-Atlas, glTF + Draco + KTX2/Basis
Tracking	MediaPipe Pose (33 Landmarks) + 8 eigene abgeleitete Punkte
Filterung	One-Euro-Filter mit adaptivem Cutoff, ausreißerrobuste Skalenschätzung
Rendering	Three.js, WebGL, Segmentierung für Verdeckungen
Threading	Inferenz im Web Worker, Rendering im Main Thread
Ausführung	vollständig clientseitig: kein Videoframe verlässt das Gerät

Zusammengefasst

Das Ergebnis ist ein Virtual Try-On, das am bestehenden Katalog andockt, statt einen parallelen Produktionsablauf zu verlangen: Die Fotos, die der E-Commerce ohnehin produziert, werden zu 3D-Assets, und der Nutzer probiert das Kleidungsstück im Browser an, ohne etwas zu installieren.

Für die Partner-Agentur ist das kein einmaliges Projekt, sondern ein Dienst im Portfolio: Die Pipeline ist für jeden Kunden dieselbe, und die Kosten für die Anbindung eines neuen Katalogs sind niedrig genug, um daraus ein wiederholbares Angebot zu machen.

---

Möchten Sie das Virtual Try-On in Aktion sehen? Demo buchen, wir zeigen es live an Ihrem Katalog.

Virtual Try-On umgesetzt von Rayo Consulting für eine Partner-Web-Agentur.