Question: Supporting stitched garment pieces (piece meshes + seam constraints) instead of single cloth OBJ

[jjqcat]

Hello XRtailor team,

First of all, thank you for open-sourcing XRtailor — it’s a very impressive project.

I have a question regarding the garment input pipeline and a possible extension.

Currently, as far as I understand, XRtailor requires the garment to be provided as a single, fully stitched cloth OBJ mesh as input. In my workflow, however, garments are initially represented as separate cloth pieces (piece meshes in 3D), together with sewing information (i.e. which edges are stitched together, seam correspondence, and seam length constraints).

I would like to ask:

Is it theoretically feasible to modify XRtailor so that it accepts:

multiple cloth piece meshes (3D), and

explicit sewing information (edge pairs + length constraints),
and then performs cloth simulation by enforcing seam constraints and collision, instead of requiring a pre-stitched cloth mesh?

Does XRtailor already have any internal support (or partial support) for:

seam / stitching constraints,

distance or length constraints between boundary vertices,

or multi-piece cloth assembly during simulation?

If not currently supported, do you think this would be a reasonable direction to extend the codebase (e.g. adding seam constraints before or during simulation), or are there architectural assumptions that strongly depend on a single connected cloth mesh?

My goal is to simulate garment assembly similar to fashion CAD workflows, where stitching is defined explicitly rather than baked into the mesh connectivity.

Any guidance on where in the codebase this could be explored (constraint system, solver stage, or preprocessing) would be greatly appreciated.

Thank you very much for your time and for sharing your work.

Best regards,
jjqcat

[WYK96]

Hi @jjqcat ,

Thank you for your interest in XRTailor and for the detailed and thoughtful question.

To facilitate large-scale data synthesis, garments in XRTailor are currently represented as a single, fully stitched cloth mesh, rather than separated cloth pieces. This design choice was made mainly for the following reasons:

• Computational cost. Stitching cloth pieces requires additional sewing constraints, which increases the computational budget during simulation.
• Initialization complexity. If the simulation input consists of multiple cloth pieces, they must be placed into appropriate initial positions to dress the avatar. When the avatar’s body shape varies, these pieces would need to be rearranged accordingly, which is a non-trivial process to automate robustly.

For these reasons, sewing-pattern–based inputs are not natively supported in the current XRTailor pipeline.

That said, this is a very valuable idea, and extending XRTailor in this direction is technically feasible. Related contributions would be very welcome. Conceptually, to support such a workflow, you would need to:

• Prepare individual cloth pieces along with sewing line metadata(e.g., edge- or vertex-level correspondences between garment patterns).
• During simulation, model each sewing line as a constraint whose two sides gradually shorten until they overlap.
• From a physics perspective, a sewing line can be treated as a spring-like constraint, similar to the existing binding constraint,
  but with zero rest length and progressive stretch stiffness.

We found that ARCSim supports cloth simulation starting from separate garment pieces, and it may serve as a useful reference for this type of functionality.

Regarding integration into the pipeline, we recommend implementing the stitching process in a pre-simulation stage, where the cloth relaxes from its initial configuration while the obstacle (avatar) remains unchanged. You may find it helpful to start from
ClothSolverBase.cpp to explore how such a stage could be incorporated.

We appreciate your interest and hope this provides some useful guidance.

Best regards,