Help Poor performance when enabled surface collision

[snowtv]

Tearable cloth preallocates enough particles to deal with the case that a given percentage of edges are torn (by default, all edges) without any runtime memory allocation. Most these particles start as inactive, and get activated as the cloth is torn and new particles are required. This doesn’t mean all 9000 particles are part of the simulation, only that memory has been allocated for them.

Regulat cloth cannot be torn, so it does not preallocate any extra particles.


Surface collisions are not “perfect” by any means, they’re just an approximation of full geometry collision detection which is extremely expensive (detecting and solving all vertex-vertex, edge-edge and triangle-vertex contacts). This approximation treats triangles as simplices and assume only 1 contact point per simplex-object pair. Contact information is also iteratively arrived at, so it isn’t 100% correct either: you can trade performance for accuracy by changing the amount of “surface collision iterations” in the solver component.

While surface collisions can be regarded as a form of spatial supersampling, they don’t perform any kind of temporal supersampling. So they won’t improve continuous collision detection against fast moving objects in any way. If you want finer temporal resolution, increase the amount of substeps.

What is your solver’s “max depenetration” velocity setting, and which update mode (sequential or parallel) are you using for collision constraints?


This is a good idea if you require very precise collision detection against very thin objects, moving at arbitrarily large speeds. Its also how picking/grabbing objects is implemented in pretty much all games: picking generally does not rely on physical contact calculations because by the time you get accurate enough interaction by cranking parameters up, collision detection becomes extremely expensive and can never be as robust as kinematically pinning/fixing/attaching two objects.

The included utility script “ObiContactGrabber” does this, but instead of being velocity based it exposes two public methods Grab() and Release() that allow you to grab and release any particles in contact with a given collider.

Thanks for the feedback! I've thought about another alternative to the "cheat" method I mentioned in the last post. The alternative I'm thinking is to create Unity mesh colliders at the potential point of collision, then blocks the potential penetration using Unity's collision physics. But I'm not sure which of these two methods is more reliable/easier to implement/easier to tweak.

I'll try to explain the mesh collider method:

for each potential contacting point, create a collision cluster

one cluster is consist of several overlapping flat mesh colliders formed from an area of particles, where the most overlapped area is the most likely point of collision with the potential contact point

each collider should have a trigger which size is a bit larger, when a collider enters the trigger, that collider should "harden" itself and stop deforming with its corresponding cloth particles, and attach the particles to its vertices using pin constraint

when the particles in a cluster "bends" beyond an angle threshold, all the mesh colliders in this cluster should "harden", which will stop the deformation of all the particles in this collider by pinning them to the mesh colliders