Loading...
> >

Why does Dforce simulation ignore the cancel button?

backgroundbackground Posts: 404
edited September 20 in The Commons

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.

Post edited by background on

Comments

  • Matt_CastleMatt_Castle Posts: 2,542
    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.
  • backgroundbackground Posts: 404
    edited September 20

    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". 

    Post edited by background on
  • richardandtracyrichardandtracy Posts: 5,617
    edited September 20

    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 

    Post edited by richardandtracy on
  • Richard HaseltineRichard Haseltine Posts: 100,481

    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).

  • crosswindcrosswind Posts: 6,831

    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 ~~ 

  • columbinecolumbine Posts: 443

    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.

  • LeatherGryphonLeatherGryphon Posts: 11,485
    edited September 23

    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.frown​  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.

    Post edited by LeatherGryphon on
  • Richard HaseltineRichard Haseltine Posts: 100,481

    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.frown​  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.

Sign In or Register to comment.