dforce crashes/freezes/explosions
tl;dr: We really need either dforce to have better internal detection of its errors (probably something only nvidia can do), or exposure of a more reliable means to cancel it.
When dforce goes especially bad, the only option is to kill the entire app, reload the scene, change some parameters, and hope it works. This can take several minutes on each attempt and there's no indication until hitting the button as to whether it's going to behave as expected or cause another total app freeze.
The cancel button in that window is fine, but it only works if you catch the process prior to the erronneous part of the simulation...which isn't obvious until it's too late.
We need the cancel button to remain available through the entire process.
Comments
It isn't NVidia developing dForce.
That said, what usually takes time is if you have many edges violating the collision distance, i.e. if you have a very dense mesh.
If I dForce an object not intended for dForce, I first look at it in texture wireshaded to determin if there seems to be critical areas.
If you run dForce you can see in the log shortest edge length and adjust the collision distance.
But there are objects that is basically not made for dForce, and where you can't get dForce to behave, unless you take them into a modeller and adjust, or weightpaint the critical areas out of the simulation.
While that's all fine and good, the tool still needs to be better able to detect runaway simulations that cause the whole interface to freeze. This specific error behavior makes all the other troubleshooting much more painful.
Having the initial evaluation of spring lengths process the main event loop - to make it cancellable - would probably be an inefficient use of resoruces (i.e. would make the process slow for most users).