Fabric digitisation replaces a hanging swatch with two unrelated measurements: how the cloth reflects light, and how it resists being deformed. The optical half becomes per-texel reflectance parameters baked into aligned image maps. The mechanical half is a short record of scalars - areal density, thickness, bending, tensile and shear stiffness, friction - that a cloth solver reads as coefficients. Only one half has anything to do with drape.
Key takeaways
- Optical capture fits a reflectance model per texel: it describes appearance, not how a fabric hangs.
- The mechanical record is a handful of direction-dependent scalars, and the solver you feed decides what they mean.
- Thickness and areal density carry more of a simulation than anything else: they set node mass and collision offset.
- A digitised material is reusable only if its record traces back to an identified swatch with a known finish.
- Pile, coatings and knit loop structure are where the capture model is weakest.
What does fabric digitisation actually measure?
Appearance is a question about light: given the direction light arrives from and the direction you view from, what fraction leaves the surface? That function is the bidirectional reflectance distribution function, or BRDF. A textile is not uniform, so the useful object is a spatially varying BRDF - one parameter set per texel, which is what makes a weave shade correctly at a grazing angle instead of reading as printed paper. Sheers need a transmission term too.
Behaviour is a question about mechanics: how much force to stretch the cloth, bend it, shear it; how much it weighs per unit area; how it rubs against itself. Those coefficients are the only reason a simulated bias-cut skirt moves differently from a simulated denim panel.
Vizoo sells hardware and software for both halves: xTex for high-resolution scanning of materials into physically based render maps, and physX for fast acquisition of physical fabric properties, with output meant to be read directly by mainstream 3D apparel design tools.
How does a scanner turn a swatch into an appearance model?
The rig is deliberately boring: the swatch lies flat under a fixed camera while a set of lights fires from known positions, one at a time. What lands on disk is an image stack - the same texels under many known illumination directions.
The fit is inverse rendering. For every texel the software solves for the reflectance parameters that best explain the observed intensities across that stack - diffuse albedo, surface normal, roughness, specular level, an anisotropy direction where the weave has one, transmission for sheers. Those parameters are written out as aligned raster maps.
Three pieces of metadata make the maps physical rather than decorative: scale in millimetres per pixel, so the weave renders at true size; a tileable crop, so it repeats across a large panel without a visible seam; and a declared colour space, so an albedo means the same thing in the renderer as in the scanner.
A normal map stores a perturbed surface direction per texel as a colour-encoded vector, which is why a scanned twill catches light along its diagonal with no geometry added; a height map stores relative elevation, which a renderer can turn into silhouette at a panel edge.
What defeats the fit is consistent: high-loft pile, where fibres stand off the surface and no per-texel normal describes them; metallic yarns that saturate the sensor; iridescent finishes whose colour depends on viewing angle; and sequins, which are geometry pretending to be texture. Stretch fabrics are scanned relaxed, so a panel the simulation pulls taut still renders at relaxed yarn spacing.
How are the mechanical properties measured?
The test battery is small, old, and predates every piece of software in this pipeline.
- Areal density. Mass of a known area, weighed. Becomes per-node mass in the solver.
- Thickness. Compression between plates at a defined pressure. Becomes the collision offset, and decides how much volume a seam builds.
- Bending rigidity. A clamped strip drooping under its own weight, measured along warp, weft and the bias separately, because woven cloth is not isotropic.
- Tensile stiffness. A strip extended under a load cell, giving a force-extension curve reduced to a stiffness - and because that curve is not straight, the reduction is already a modelling decision.
- Shear stiffness. In-plane deformation in a hinged frame; the property that decides whether a bias panel breaks into soft folds or stiff cones.
- Friction. Fabric on fabric and fabric on skin, which makes a lining slide instead of drag.
Hysteresis is the value most often discarded: real cloth does not return along the path it took, and most solvers have nowhere to put it, so the loop collapses into a single stiffness.
How is a digitised material encoded, and what travels between tools?
Two payloads bound to one identity. The appearance payload is the raster stack with its scale, tiling and colour space. The mechanical payload is a scalar record - the values above, keyed by direction, with their units.
The identity is what teams underestimate. A record worth keeping carries supplier, composition, construction, colourway, finish and a pointer back to the physical swatch, because the same greige cloth with a different finish is a different material in both halves of the measurement - the discipline problem our piece on garment geometry as model input describes on the pattern side.
The mechanical values are also less portable than the maps. A mass-spring solver, a position-based dynamics solver and a finite-element solver parameterise stiffness in different quantities and units, with different assumptions about what a spring spans, so vendors ship per-solver parameter sets derived from one measurement session. A value lifted from one solver into another produces confidently wrong drape.
What consumes the data once it is in the pipeline?
| Consumer | What it reads | What a wrong value looks like |
|---|---|---|
| Cloth solver | density, bending, tensile, shear, friction, thickness | a jacket that hangs like sheet plastic |
| Renderer | reflectance maps, scale, tiling, colour space | right silhouette, fabric like printed paper |
| Fit review | thickness, stretch | ease that evaporates once the garment is sewn |
| Costing | density, width, pattern repeat | requirements that miss at the cutting table |
Vendors sit at different points on that chain. Seddi runs Textura.ai, a cloud platform for producing 3D digital textiles, and ships Decorator, a 3D workspace that builds true-to-pattern digital replicas of blank garments for artwork placement and production instruction. Frontier.cool takes the library route: TextileCloud digitises fabric into texture maps and physics data, then serves it as a searchable cloud library with vendor portals and PLM integration.
Trade coverage has been pointing this way for a while: a Premiere Vision briefing on material innovation published in October 2024 placed AI-enhanced material digitisation among the next steps for 3D simulation.
Should you digitise your own library or source the data?
The question is rarely accuracy. It is coverage and turnaround.
Your own scanner buys control over which fabrics get captured and when, plus a re-scan when a supplier changes a finish. You pay with a calibrated space, a trained operator and a QA habit: someone checks every tile for seams, every albedo against a swatch under known light, every record against the drape of the real cloth. Sourcing removes the capital cost and moves the constraint to coverage - a library only helps if it holds the mills you buy from, in the finishes you order. Either way, insist on both halves: an appearance-only material renders beautifully and simulates like a paper bag.
What is still unsolved?
Finishing is the largest gap. Coatings, calendering, washing and softeners change both reflectance and mechanics after the point where most libraries were captured, and nothing in the encoding follows a material through its finishing route. Knits are close behind: the capture model assumes a surface, while a knit is a loop structure whose behaviour emerges below the texel, which is why knits simulate acceptably in bulk and badly at the rib.
Then validation. No shared round-trip test certifies a digitised material against the real one; draping a circular sample over a disc is the informal check, and nothing enforces it. Until something does, accuracy means whatever a vendor's fitting procedure produces - the same gap our note on computer vision for textile defect detection describes for inspection.
FAQ
Is a scanned fabric the same thing as a photograph of it?
No. A photograph fixes one illumination and one viewpoint. A scan fits reflectance parameters per texel across many known illuminations, so a renderer can compute appearance under lighting the scanner never used.
Can appearance maps alone drive a simulation?
No. Maps describe light, not force. Without areal density, thickness, bending, tensile and shear values, a solver has nothing to compute drape from and falls back on a default fabric.
Why do one fabric's stiffness values differ between tools?
Because each solver parameterises cloth differently. Values fitted for a mass-spring model do not mean the same thing in a finite-element or position-based solver, so vendors derive a parameter set per target.
Does digitisation remove the need for physical swatches?
No. The swatch stays the ground truth a digital record is validated against, and the only way to catch a finish change the library was never told about.
Further reading
- A June 2025 research review in the Journal of Textile Engineering & Fashion Technology on what virtual sampling replaces.
- McKinsey's assessment of generative AI in fashion, published in March 2023, for the commercial framing around product development.