This isn't as complicated a problem as you think -- you just need to remember that collision constraints are a type of constraint, and solve them *together* with the distance constraints in your solving loop.

eg something like:

for(num_solver_iterations)
{
SolveDistanceConstraints();
SolveCollisionConstraints();
}

Of course, this moves collision detection to inside your solver loop, which is bad for performance. Typically people cache the broadphase and update the narrow phase, i.e your collision data knows the face+vertex that are colliding, and when solving the collision constraint you first check if collision is happening (which you have to do anyway to calculate the error term) and if not you skip solving it this iteration.

I hope this makes sense!

Thanks raigan, I tried something like below:

FindCollisionParticles(); // if found one, then mark this particle isActive = false; which makes it also not movable by its physical update or constraints.

for (num_iterations)

{

SolveDistanceConstraints();

}

// at the end of the update

RecoverDeactivatedParticles(); // Reactive particles that are marked deactive in FindCollisionParticles();

Somehow this doesn't work for me.

Sorry, maybe I didn't explain very well: you need to handle collision *just like a constraint*, i.e you need to solve both collisions and other constraints together in the loop, otherwise the solver won't converge nicely.

Something like:

for (num_iterations)
{
    SolveDistanceConstraints();
    SolveCollisionConstraints();
}

This way the constraint forces can "talk" to each other and find a mutually acceptable equilibrium state.

Of course: what does SolveCollisionConstraints() look like? There are many ways of implementing this; the un-optimized version is to run a full broad+narrow phase collision in here, but that gets slow. Instead you can cache the pairs returned by the broadphase before solving, and re-run narrow phase (i.e calculate the vert-face or edge-edge penetration depth and project out of collision if the two features are penetrating).

JoeJ's approach also works, AFAICT it's Jacobi iterations instead of Gauss-Seidel -- see the paper "Mass Splitting for Jitter-Free Parallel Rigid Body Simulation" for more info: IIRC you shouldn't be scaling by some arbitrary number but instead averaging all particle displacements based on relative mass. The paper has more details. The downside to Jacobi is that it converges more slowly.

Thanks raigan,

I'm now focusing on the cloth simulation on an animated character. I tried to use a AABB hierachy for the character, and use a 3d grid spatial hashing for the broad phase collision detection, yes, for an AABB, I calculate its center and min and max, find which grids it's in, this part is fast, since it's just simple calculations. But since the character is animated, the AABB needs to be updated every frame, and besides, there is no access to the SkinnedMeshRenderer's current skinned vertices' position, I have to do the skinning my self. So the flow would look like:

UpdateOfACharacter()

{

Skinning Character();

Update Character AABB();

Update AABB spatial hashing();

}

UpdateOfAClothObject()

{

UpdateVerletIntegration();

UpdateConstraints(); // Through iterations of cause.

UpdateClothParticleSpatialHashing();

}

then Do the Collision Operations.

I found this process not running so fast, avg 25 FPS on a CPU i5 7500(on my android device it count down to 16 FPS on avg). Running with unity, C#, no multi-threading used yet.

So now I'm trying to do something unity cloth has already accomplished: cloth simulation blending animation and physics.

The idea is to do the physics first, and the compare the physics particles position with skinned vertices position, and find a proper way to blend those two, it's collision free, so it could be really fast.

I just need to figure out how to blend those positions... Don't know how to do that yet...