Help Poor performance when enabled surface collision

[josemendez]

I'm getting 9k "used particles" in the solver when I have one active cloth actor under it, is it because I'm using the TearableCloth? I do see it drops to 1.5k when switch to non-tearable cloth.

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.

I also got better results with surface collision after I reduced the particle size when generating the blueprint, however, the surface collision is definitely not "perfect". In my project there will be very pointy objects that will be interacting with the cloth mesh, and they seem to still penetrating the mesh if moving fast enough.

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.

Another big issue is that if the cloth is squeezed between two colliders, it will go into a sort of "death spiraling" and can't stop jittering and destroy the performance.

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

Currently I'm thinking about a way to "cheat" the collision, by adding a temporary pin constraint when my pointy tools collide with the cloth, so the cloth particle is basically attached to the tool, and I'm thinking to check the tool's movement vector against the pinned particle's normal, to remove the pin constraint when the tool is not moving towards the cloth object. Has anybody tried that before?

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.