Erst nähen, dann fallen lassen
In frühen Versionen fiel der Stoff schon, während die Nähte noch gesucht wurden. Das Shirt hat sich verdreht, gedehnt oder die passende Kante verfehlt. Besser: erst Nähte schließen, Topologie mergen, danach drapen.
← Zurück01 — 06
Systems2025 – 2026·Fallstudie
BioCloth simuliert Kleidung direkt im Browser: 2D-Schnittmuster werden zu einem Mesh, die Nähte schließen sich und der Stoff fällt auf einen animierten Avatar.
Rolle
Team von 2
Status
Aktiv
Jahr
2025 – 2026
Stack
JavaScript
Runtime + Engine-Glue
WebGPU
Compute-Pipelines
WGSL
WGSL
Solver-Shader
Three.js
Scene + Rendering
Links
Kern des Projekts
Physik
Am Anfang war die Idee: Kleidungsstück im Browser anzeigen, fertig. Hat nicht gereicht. Sobald Nähte falsch schließen, Collision zu spät kommt oder Performance einbricht, wirkt es nicht nur unsauber, sondern kaputt. BioCloth wurde deshalb eher Engine-Arbeit als UI-Projekt.
94×
Capture-Readback nach Pipelining schneller
<1 min
geschätzte komplette Precompute-Zeit
Replay
Layout-Fingerprint-Cache für Playback
CCD+
Raycast-CCD plus Proximity-Pushout
Problem
Was daran schwer war
Problem
Ein T-Shirt aus zwei flachen Pattern-Teilen klingt erstmal simpel. Schwierig wird es, sobald es sich bewegen soll. Nahtkanten brauchen gleiche Samples, sonst trifft der Solver falsche Punkte. GPU-Threads dürfen nicht gleichzeitig denselben Vertex verändern. Collision muss schnell sein, aber trotzdem verhindern, dass Stoff durch den Körper rutscht. Und wenn pro Frame Daten zurück zur CPU müssen, ist Realtime fast sofort weg.
Ansatz
Startpunkt ist ein Pattern-JSON. BioCloth sampled zuerst passende Nahtkanten, füllt die Teile per Delaunay-Triangulation und lädt Particles plus Springs auf die GPU. Danach ziehen Seam-Constraints die Stoffteile zusammen. Wenn der Fehler klein genug ist, werden die Nähte wirklich gemerged. Erst dann kommen Gravity, XPBD-Springs und Collision gegen den animierten Body dazu. Für schwere Szenen gibt es Precompute/Replay: einmal auf stärkerer Hardware berechnen, Frames prüfen und später im Browser abspielen.
Pipeline
Pattern zu Motion-Cache
Jeder Schritt hat eine klare Aufgabe, ein eigenes Datenformat und Fehler, die man gezielt prüfen kann. Genau dadurch bleibt das Projekt debugbar.
Pattern
2D-Teile mit Bézier-Punkten und Seam-IDs
Mesh bauen
gleiche Naht-Samples, danach Delaunay-Fill
GPU Solve
Verlet, XPBD-Springs und CCD-Collision
Nähte mergen
aus Naht-Vertices wird ein echtes Kleidungsstück
Replay
geprüfte Precompute-Frames später abspielen
Was sich geändert hat
Was es besser gemacht hat
Nähte brauchen gleiche Punkte
Eine Naht hält nur sauber, wenn beide Kanten gleich viele Vertices haben. Remeshing prüft die Nahtpaare vor der Triangulation und erzwingt gleiche Samples. Sonst versucht der Solver zwei unterschiedliche Auflösungen zusammenzuziehen.
Collision löst viel, kostet aber
Der aktuelle Merged-Path nutzt Raycast-CCD plus Proximity-Fallback. Dadurch rutscht der Stoff deutlich seltener in den Body. Danach war aber klar: animierte Collision-Daten sind teuer, vor allem BVH-Refit und Triangle-Uploads.
Replay wurde mehr als Komfort
Replay war zuerst nur gegen langsame Reloads gedacht. Später wurde es ein echter Teil der Architektur: teure Cloth-Bewegung einmal berechnen, mit Layout-Fingerprint speichern und auf schwächeren Geräten wiederverwenden.
Technische Entscheidungen
Warum so gebaut
Lifecycle
- +Erst schließen die Nähte, dann fällt der Stoff. Gemerged wird erst, wenn der Seam-Fehler klein genug ist.
- +XPBD-Compliance hält Springs stabiler, auch wenn FPS oder Solver-Zeitschritt schwanken.
Mesh + Collision
- +Seam-Kanten bekommen vor der Triangulation gleiche Samples. Sonst passen Constraints später nicht sauber.
- +Raycast-CCD prüft Bewegung; Proximity-Pushout rettet Vertices, die schon im Body stecken.
Runtime
- +Precompute/Replay macht teure Cloth-Bewegung zu gecachten Daten, die später schnell abgespielt werden.
- +Profiling zeigt den nächsten echten Engpass: BVH-Refit und Triangle-Uploads.
Runtime
Cache ist hier kein Extra
Precompute macht aus teurer WebGPU-Arbeit normale Replay-Daten: auf stärkerem Rechner berechnen, Layout prüfen, Frames cachen und später auch auf schwächeren Geräten flüssig abspielen.
Cloud-Precompute
Stärkere Hardware kann die teuren Cloth-Frames einmal berechnen. Der Browser lädt danach geprüfte Replay-Daten, statt alles live zu lösen.
Layout-Fingerprint
Cache-Identität hängt an Settings, Pattern-Dateien, Schema-Version und Human-Model-Path. Alte Motion wird dadurch abgelehnt, statt still falsch abgespielt zu werden.
Schwächere Geräte
Replay überspringt Live-Physik und spielt gecachte Frames ab. Wichtig für Laptops oder mobile Geräte, wo WebGPU-Budget schnell knapp wird.
Was daraus rauskam
Gut / nicht gut
Hat gut funktioniert
- +Koordiniertes Naht-Sampling macht Seam-Pairing viel berechenbarer.
- +XPBD-Compliance macht Material-Tuning weniger abhängig von FPS und Zeitschritt.
- +Precompute/Replay macht aus teurer Simulation wiederverwendbare Runtime-Daten.
Hat nicht funktioniert
- -Mesh-Dichte zur Laufzeit ändern killt Constraint-Indizes. Idee verworfen.
- -Live-GPU-Readback plus CPU-Normalen kostet immer noch sichtbare Update-Rate.
- -Collision in jeder Solver-Iteration ist stabil, aber zu teuer für normale Geräte.
Nächste Baustellen
Was als Nächstes zählt
sichtbare Mesh-Updates stärker auf GPU halten, weniger CPU-Readback
Normals direkt in Precompute-Captures speichern oder auf GPU berechnen
Collision nicht immer laufen lassen: erste/letzte Iteration plus Final-Pass testen
Galerie
03
Nächstes Projekt
BioMesh
→Du arbeitest an
ähnlichen Themen?
Schreib mir kurz, worum es geht — ich melde mich.
Timo Wilde© 2026