No virtual try-on system in production today shows you how a garment will actually drape on your body, because none of them simulate the fabric. The dominant pipeline works in image space: segment a body, warp a flat garment image onto it, blend the seams, let a generative model draw the creases. Bending stiffness, shear resistance, weave geometry and weight per unit area are never represented anywhere in that pipeline, so they cannot appear in its output. You get a plausible photograph of cloth, not a prediction of its behaviour.
Key takeaways
- Image-space try-on optimises for photographic plausibility, not physical correctness, and the two diverge exactly where drape lives.
- Drape emerges from bending stiffness, shear, weight per unit area and friction — none of which exist as variables in a compositing pipeline.
- Wrinkles in a generated try-on image come from a learned prior, not from a garment's material response.
- Better body capture improves size recommendation but cannot recover material properties the garment record never stored.
- Ask a vendor which material parameters its model consumes: a texture map is not a parameter.
What does drape actually mean in physical terms?
Drape is not a look. It is the equilibrium shape cloth settles into when gravity, its own resistance to bending, and contact with a body all balance. Textile engineering measures it: hang a circular sample over a smaller pedestal and measure how much of its projected area collapses. Stiff fabrics hold a wide outline with few nodes; fluid fabrics collapse into a narrow one with deep folds.
Four properties dominate the result:
- Bending stiffness — resistance to curving; sets fold radius and whether a hem breaks softly or holds an edge.
- Shear resistance — how readily the weave distorts in-plane; decides whether a bias-cut panel spirals or hangs straight.
- Weight per unit area — the gravitational load driving every fold.
- Surface friction — how the cloth slides against skin, lining, and itself.
Change one and the same pattern, cut to the same measurements, hangs differently. Drape is a function of material, not of silhouette.
How does a virtual try-on pipeline build its image?
Trace the stages. Person parsing first: segment the photo into body regions, estimate pose keypoints, sometimes fit a parametric body model. Then garment parsing: cut the product image from its background and label sleeve, placket, hem. Then warping: compute a deformation field — thin-plate spline, optical flow, or learned dense correspondence — mapping garment pixels onto the target region. Then synthesis: a generative model composites the warped garment onto the person and hallucinates the occlusion boundaries, shadows and creases that make the join read as a photograph.
Notice what never enters. No material parameter is consumed at any stage, because no stage has a slot for one. The creases are drawn, not solved: the model learned that cloth in roughly this pose creases at roughly this frequency, so it draws that frequency. This is texture-conditioned inpainting wearing the costume of simulation.
Vendors here are usually clear about their scope. Veesual ships an image platform that turns a brand's static product visuals into short videos automatically by connecting to the product feed — a throughput problem, solved on imagery, with no claim to be a fabric solver.
Why can't a compositing pipeline recover material behaviour?
Because the information was never captured. A product photograph is a projection: one flattening of a three-dimensional cloth state, under one lighting setup, in one pose, after somebody's styling decisions on set. From it you recover colour and print reliably, texture roughly, and material mechanics not at all. Two fabrics with the same print and very different bending stiffness produce nearly identical pixels in a flat lay.
As an inverse problem it is underdetermined by construction. The forward map from material, pattern and body to image throws away dimensions, and running it backwards from pixels cannot restore them. A network learns the most likely appearance given its training set, but likelihood over a dataset is not equilibrium under gravity for one body. Where those disagree — a heavy knit on a narrow shoulder, a bias-cut skirt over a fuller hip, a stiff twill in a seated pose — the output is confidently wrong, and still looks fine in a screenshot.
A duller blocker sits underneath: the e-commerce garment record is photographs, copy and a size chart, so even a perfect solver would have nothing to solve on.
Which properties would a correct system need, and can imagery supply them?
| Property | What it governs | Recoverable from product imagery? |
|---|---|---|
| Bending stiffness | Fold radius, how a hem breaks | No — nearly invisible in a flat lay |
| Shear resistance | Whether bias panels spiral or hang straight | No — needs in-plane deformation testing |
| Weight per unit area | The load pulling each fold down | No — lives in a mill spec, not a pixel |
| Pattern geometry | Where fabric volume actually sits | No — lives in the flat pattern file |
| Colour and print | Appearance only | Yes — what imagery is genuinely good for |
Can better body data close the gap?
Partly, and it pays to be precise about which part. 3DLOOK ships FitXpress, which derives a detailed set of body measurements and body-composition estimates from smartphone photos, sold through an API and SDK into digital health, fitness and wellness platforms. Bold Metrics builds body-data digital twins for apparel shoppers and packages them into sizing products for brands. True Fit runs fit and size recommendation on product pages and search, and has been extending it into an API layer for agent-driven shopping stacks.
That covers the body side well enough for size recommendation to work. But the body is one of three inputs: give a solver an accurate body and no material parameters and you get an accurate mannequin wearing an unknown cloth. Hence the pattern brands we speak to keep describing — try-on lifts conversion while returns refuse to fall. Shoppers get a better answer to "will this fit" and none to "how will this hang".
What would a physically correct try-on require?
Three data layers, joined, and none of them are photographs.
- Garment geometry from the pattern — flat panels, grain lines, seam paths and eases that determine where volume sits. A CAD artefact that lives inside the brand and rarely reaches the storefront.
- Measured material parameters — bending, shear, tensile, weight and friction values from lab testing or a digital material library, attached to the colourway rather than the style.
- A cloth solver — a physics engine that stitches the panels, applies the material, and runs gravity and collision against a body mesh until it settles.
Three-dimensional garment design tools already run this loop inside product development, which is the tell: the physics is not the unsolved part. The obstacles are structural — solver runtime does not fit a page-load budget, per-colourway material data is rarely digitised, and pattern files sit with a brand's technical team while the try-on widget sits with e-commerce.
That lands where we land elsewhere on this site: the defensible asset is proprietary data — the pattern archive, the material library — not the model wrapped around it, and it is why the retailers making progress build design tooling inside their own platform instead of hoping to buy drape at the edge. This is plumbing between technical design and the storefront, not a vision problem waiting on a bigger model.
How should you evaluate a try-on vendor if drape matters?
Ask what a demo cannot answer:
- Which material parameters does the model take as input, and where do those values come from?
- Does the system consume pattern geometry, or only product photographs?
- Is output validated against a photograph of the same garment on the same body, or against preference ratings?
If the answers describe imagery in and imagery out, you are buying a visualisation product. Buy it for catalogue coverage and on-model imagery at scale, and keep a returns target off it.
FAQ
Does any virtual try-on tool simulate real fabric physics?
Not in the shopper-facing pipelines on product pages. Cloth simulation exists in three-dimensional garment design software used in product development, but it needs pattern files and material data that storefront try-on systems never receive.
Why do generated try-on images still show wrinkles?
They come from a learned image prior: the model reproduces crease patterns common in its training data for a similar pose and garment shape. Plausible decoration, not the result of solving how that fabric folds.
Would a more accurate body scan fix drape accuracy?
No. Body geometry is one input; material behaviour and pattern geometry are the others. An accurate body improves size recommendation, but with no stiffness or weight values nothing can predict how cloth hangs.
Can fabric properties be estimated from a product photo?
Not reliably. The mapping from material to image discards the dimensions needed to invert it, and two fabrics with the same print and different stiffness look almost identical. Mechanical values come from testing, not pixels.
Further reading
- Fashion Meets Computer Vision: A Survey — a map of detection, parsing and synthesis tasks, and where try-on sits.
- Computer Vision for Fashion: A Systematic Review of Design Applications — how vision methods apply across fashion design and production.