Instability in Flex cloth tearing

I’ve been trying to use Flex for a cloth simulation, and I’ve been seeing some instability, so I went back to the Flex demo application and was able to replicate the problem there.

What I’m seeing is that whilst almost all the cloth demos are very resilient to being yanked about, the cloth tearing demo will explode if you give the cloth a sharp tug. This is similar to what I’m seeing in my own application, where the simulation is liable to explode when distance constraints are put under severe strain.

I’ve uploaded some videos to dropbox demonstrating the problem. Here is the tearing from the v110 demo demonstrating the problem, and the same problem in the v100 demo. I’ve also uploaded a video of the flag demo from v110 showing it behaving correctly under severe strain. That said, I don’t think the tearing itself is necessarily the problem, as removing the call to NvFlexExtTearClothMesh from the demo doesn’t fix the problem.

Interestingly this problem doesn’t seem to have existed in earlier versions of Flex. I tested this on the v090 demo and it worked fine (see video). I also found this gif uploaded shortly after Flex was announced, which also seems to demonstrate the correct behaviour, although as I didn’t make it, I don’t know the exact version it shows.

For reference, I got these results testing v090, v100, and v110 (CUDA & D3D) on a GTX 980 Ti, and then replicated the problem in the D3D version of the v110 demo on a GTX 1060 and an AMD RX 480 with the same results.

In terms of what appears to be happening under the hood, it seems like a classic physics explosion, with the particle locations rapidly increasing over the course of a few frames until the numbers presumably become too big, at which point the simulation is left with a particle buffer full of NaNs.

If anyone has any insights on this problem, can replicate it, or can suggest any solutions, it would be greatly appreciated. Thanks!

Hi Laurie,

With iterative solvers like the ones used in Flex there is a trade-off between convergence speed and robustness / stability.

Flex supports two ways of controlling convergence through the NvFlexRelaxationMode enum. The tearing scene uses a fixed global relaxation parameter, which is known to be less robust, but can give better convergence than the adaptive local method. I believe we switched the tearing scene from local to global at some point around 0.9.0, and this is probably why you are seeing some stability issues under large strain.

If you have a scene where you expect large strains then I would recommend using the local relaxation mode, at the cost of some convergence speed.

As a side note, we are now recommending to use Github for reporting issues:

Cheers,
Miles

Hi Miles,

Thanks for the quick response! Yes you’re absolutely right. I tried changing the demo over to using local relaxation and the problem went away. In my own application, it also prevents the large numbers and NaNs, although it does seem to make things stretch a great deal more than they did before. That’s probably something to be solved just by playing with the other parameters though.

Anyhow thanks very much for your help, and for letting me know about the GitHub issues list. I’ll be sure to post issues there in future.

Cheers!