What can I adjust to stop a cloth from doing through a collision mesh?

[MoonBoop]

Are you generating the garment meshes programmatically? for instance, delaunay triangulation of a bezier patch. If so there's a good chance that your mesh does not have any uv/normal/color discontinuity (at least not for each individual garment piece).

Yup, that is the approach we're taking with generation. We're using a cubic spline drawing of the garment and using Delaunay triangulation to extract a mesh out of the garment drawing.

and yea, each piece it being processed separately.

When triangulating the garment piece to generate a mesh, I create the vertices at the borders last, this way I have an easy way to identify vertices at the borders: they're always at the end of the mesh vertex list.

I might try that change with my implementation.


atm with my implementation Im having to retrieve if a vertex is on a curve and if that curve can be stitched, it would yea be simpler if I could just have the vertices that need to be stitched at the end of the vertex list to make stitching simpler.



I have done a debug of the curves that are being stitched, which did reveal a bug of that I wasn't stitching everything, but there is still the problem of things flying off of the model.

[josemendez]

I have done a debug of the curves that are being stitched, which did reveal a bug of that I wasn't stitching everything, but there is still the problem of things flying off of the model.

You can add a ObiParticleRenderer component to your cloth in order to visually inspect/debug the particle representation. That might reveal issues with collision response.

It's hard to diagnose this without taking a direct look at the project, since it could be many things: incorrect collider setup (large collider thickness), incorrect stitching, scaling issues (mesh transform scale > 1 to compensate for a smaller mesh, which would result in cloth shrinking at runtime), etc. If you deem it necessary, you can send the project to support(at)virtualmethodstudio.com and I'll be glad to take a look at it as soon as I can.

[MoonBoop]

If you deem it necessary, you can send the project to support(at)virtualmethodstudio.com and I'll be glad to take a look at it as soon as I can.

I'll have to wait to hear back if it is possible to share the project or not, but if so then Ill be on contact soon about sharing it.

 incorrect collider setup (large collider thickness)

The thickness was only set to 0.01f



The particle renderer doesn't really shed much light as to what is happening.


mores it shows that the particles are behaving eratically.

---

Would a meeting screen share be possible?

[josemendez]

I'll have to wait to hear back if it is possible to share the project or not, but if so then Ill be on contact soon about sharing it.

The thickness was only set to 0.01f

The particle renderer doesn't really shed much light as to what is happening.

Try the following, add this method to the end of ObiStitcher.cs:

Code:

public void OnDrawGizmos()
        {
            Gizmos.color = Color.red;
            Gizmos.matrix = actor1.solver.transform.localToWorldMatrix;
            for (int i = 0; i < stitches.Count; i++)
            {
                int p1 = particleIndices[i * 2];
                int p2 = particleIndices[i * 2 + 1];
                Gizmos.DrawLine(actor1.solver.renderablePositions[p1], actor1.solver.renderablePositions[p2]);
            }
        }

Then, enable gizmos in your scene view (button at the top right). This will show the stitch constraints as red lines at runtime:



This way you can verify if the correct particles are being stitched.

Also, setting the relaxation factor in the solver->constraints->stitch constraints to 0.1 will "smoothen out" the constraints, allowing you to see exactly what's happening. You can also reduce the project's timescale for a slow-motion effect for better insight.

Would a meeting screen share be possible?

Don't know if there's anything a screen meeting would allow us to do that can't be done here, specially since this can probably only be solved by debugging trough the code.

[MoonBoop]

okay, it has helped in showing that im getting a completely different stitching result to what Ive been expecting, though it does leave me now confused as to why.

[josemendez]

okay, it has helped in showing that im getting a completely different stitching result to what Ive been expecting, though it does leave me now confused as to why.

Double check that the amount of particles and vertices in your garment are exactly the same:

Code:

int vertices1 = (actor1 as ObiCloth).clothBlueprint.inputMesh.vertexCount;
int particles1 = actor1.activeParticleCount;

Debug.Log("There's " + vertices1 + " vertices and " + particles1 + " particles in the first cloth.");

int vertices2 = (actor2 as ObiCloth).clothBlueprint.inputMesh.vertexCount;
int particles2 = actor2.activeParticleCount;

Debug.Log("There's " + vertices2 + " vertices and " + particles2 + " particles in the second cloth.");

Placed in the stitcher's OnDrawGizmos method (together with the previous stitch drawing code), this code will spam your console with messages about the number or vertices and particles in each cloth.

If these don't match, it means the mesh has discontinuities - though it shouldn't. If this is the case, either fix it - is there any chance you're generating 3 unique vertices per triangle when building your mesh, instead of sharing the same vertex position for all incident faces? -  or use the blueprint to map from vertex index to particle index (using cloth.clothBlueprint.Topology.rawToWelded).

[MoonBoop]

I've got the latest changes in from the email you sent, and it's working better now, but when I try to use multiple distance fields, I run into a problem now where the cloth is glitching on the torso.

the velocity of the cloth on the back of the mannequin is spiking wildly everywhere.

it only does this spiking when multiple signed distance fields are on, if I use a single signed distance field then the cloth is mostly fine.

[josemendez]

In case anyone reading this thread wonders how it went and what caused the spiking, the reason was the initially concave distance field was split into multiple smaller, but still concave fields. Using separate convex fields attached to each of the character's bones did the trick.