Why does Dforce simulation ignore the cancel button?

background

If I'm running a Dforce simulation, sometimes I see the simulation has reached a point where I'm happy with the result, or maybe I see the beginnings of what I suspect will be an explosion. When this happens I can try pressing the cancel button, but the olnly result is that the cancel button disappears. The Dforce simulation totally ignores my attempts to stop it. Is this deliberate? What would be difficult for studio to stop processing the simulation as soon as I press the button.

The fact that the cancel button disappears indicates that Studio has registered the button has been pressed, so it's not like the process is too busy to register user input.

Matt_Castle

Yes, it's deliberate. The window and the dForce process are separate, and the window is waiting for the next interrupt in the dForce process, because having more frequent interrupts in the process would significantly slow down the simulation.

background

Hmmm, the least it could do is a Douglas Addams style , by lighting up with a message saying "Please do not press that button again". 

richardandtracy

That would require the dForce simulation to be programmed differently.

I suspect the dForce calculation loop has a refresh/update/screen redraw at the beginning or end of each step calculation loop. As it approaches a crash, each step calculation loop has an increasing number of convergence iteration loops inside the step calculation loop. This means that the refresh/update/screen redraws happen at increasing intervals, which is why responsiveness reduces.

To prevent this, it would have to be reprogrammed with the window in one thread, the dForce calculation in another thread and the window cancel button trigger a common 'cancel' variable checked by the iteration loop every pass - normally separate threads are prevented from having common variables to prevent timing mix-ups. To safely write to the common variables, the dForce thread would have to be frozen through triggering a special method written into the dForce thread unit. This would allow the button to have a new message displayed, as you suggest.

I have programmed something like this myself, and the time to programme it this way is inordinately more for a slight overall program performance reduction and small improvement in responsiveness when things go wrong. So, there are reasons for doing it the way it is, however much we might prefer it to be different.

Regards, 

Richard 

Richard Haseltine

Cancel should work during the actual simualtion, it did for me the other evening. It will not work during the preliminary phase, if you are getting a string of warnings about edges being shorter than the minimum offset (which may indeed prefigure an explosion, so you might well be trying to cancel then).

crosswind

Cancel button always works... even with an explosion seen in your Viewport, but you just have to wait the simulation session responsive as there's usually an interval before the simulation thread is unfrozen ~~ 

columbine

background said:

Hmmm, the least it could do is a Douglas Addams style , by lighting up with a message saying "Please do not press that button again". 

I laughed.

LeatherGryphon

I fought this phenomenon 40+ years ago.  I use to write real-time, multi-process, multi-processor, operating systems and applications for robots and communication systems where response time was critical.  It's an easily arising problem caused by one or more of the following:  Cross-dependent processes, uninteruptability, greedy sub-processes, lazy programming, poor design, hardware autonomy usurping software intentions, careless updates, too many cooks in the kitchen.​  Failure to take into account the event relationships and timing possibilities could lead to delay-frustration, crash or gridlock.  That's where I learned that regardless of how unlikely an event is, in the fullness of space and time, anything not forbidden is inevitable.

Richard Haseltine

LeatherGryphon said:

I fought this phenomenon 40+ years ago.  I use to write real-time, multi-process, multi-processor, operating systems and applications for robots and communication systems where response time was critical.  It's an easily arising problem caused by one or more of the following:  Cross-dependent processes, uninteruptability, greedy sub-processes, lazy programming, poor design, hardware autonomy usurping software intentions, careless updates, too many cooks in the kitchen.​  Failure to take into account the event relationships and timing possibilities could lead to delay-frustration, crash or gridlock.  That's where I learned that regardless of how unlikely an event is, in the fullness of space and time, anything not forbidden is inevitable.

In this case I beleive the lack of cancel in prep was because in well designed clothes there should be little need for the springs too short warning, and each loop of the check is fast enough that adding an event queue check would actually make it slower by enough to be annoying. The slow response, as with slow cancelling in renders, during the actual simulation process is because it can't close until the currently spawned processes releasse their data and can be cleared up.