Why do dForce 'explosions' take so long to recover from?

Uh-oh! That dress you were simulating was doing just fine... until it wasn't! The bar is at 71% but all of your hopes of gracefully draping the cloth over the figure are gone now.

You hit 'cancel,' and wait.

And wait.

And wait.

What gives? Does a dForce failure cause Daz to enter a death-spiral of futile math equations? Is it still bravely trying to salvage the ruined dress even though you asked it to stop?

Normally I'd chalk it up to memory/CPU usage, but when you early exit a dForce simulation pre-explosion there's never any delay or hang-ups, so I'm assuming the fault lies with that moment where it all goes wrong?

Comments

  • crosswindcrosswind Posts: 6,974
    edited January 25

    Yep, that's the fact...Though DS is a single threaded application, as well as most of its internal functions, dForce plugin (as well as almost all of the plugins) is mult-threaded. That's why a simulation with normal collision / iteration process is still quickly responsive to user's operation, e.g. clicking Cancel button.

    However, an explosion is accompanied with a "complex calculation" of how the intersected and/or contracted geometry (polygons, edges and vertices...) collide with iterations, or in other words, how the geometry will explode frown In this process, esp. at the moment before a "real explosion",  the thread is more or less hung there with pretty slow response to user's Cancel action. Besides, dForce simulation is processed by graphics card other than CPU, so a slow speed in some complex cases is unsurprising....

    Post edited by crosswind on
  • Richard HaseltineRichard Haseltine Posts: 100,905

    crosswind said:

    Yep, that's the fact...Though DS is a single threaded application, as well as most of its internal functions, dForce plugin (as well as almost all of the plugins) is mult-threaded. That's why a simulation with normal collision / iteration process is still quickly responsive to user's operation, e.g. clicking Cancel button.

    However, an explosion is accompanied with a "complex calculation" of how the intersected and/or contracted geometry (polygons, edges and vertices...) collide with iterations, or in other words, how the geometry will explode frown In this process, esp. at the moment before a "real explosion",  the thread is more or less hung there with pretty slow response to user's Cancel action. Besides, dForce simulation is processed by graphics card other than CPU, so a slow speed in some complex cases is unsurprising....

    I am told this is incorrect, at least in parts (calling DS single-threaded without qualification ius not, as far as I know, correct). Explosions do generally mean that there is more energy going into the system than can be diffused, but that doesn't inherently mean that the simulation is "complex".

  • crosswindcrosswind Posts: 6,974
    edited January 25

    Richard Haseltine said:

    crosswind said:

    Yep, that's the fact...Though DS is a single threaded application, as well as most of its internal functions, dForce plugin (as well as almost all of the plugins) is mult-threaded. That's why a simulation with normal collision / iteration process is still quickly responsive to user's operation, e.g. clicking Cancel button.

    However, an explosion is accompanied with a "complex calculation" of how the intersected and/or contracted geometry (polygons, edges and vertices...) collide with iterations, or in other words, how the geometry will explode frown In this process, esp. at the moment before a "real explosion",  the thread is more or less hung there with pretty slow response to user's Cancel action. Besides, dForce simulation is processed by graphics card other than CPU, so a slow speed in some complex cases is unsurprising....

    I am told this is incorrect, at least in parts (calling DS single-threaded without qualification ius not, as far as I know, correct). Explosions do generally mean that there is more energy going into the system than can be diffused, but that doesn't inherently mean that the simulation is "complex".

    But with my experiments for years, the fact is, for instance, different Collision Mode will result in different simulation result and time, as well as the response performance to user's Cancel action. A discrete collision is less "complex" (probably not a proper word...) than continuous CCD. The explosion results are also different.

    Post edited by crosswind on
  • Sven DullahSven Dullah Posts: 7,621

    ...well, sometimes you just have to embrace the dForce gods...devil

    The Black Rose

  • crosswindcrosswind Posts: 6,974

    Sven Dullah said:

    ...well, sometimes you just have to embrace the dForce gods...devil

    The Black Rose

    This, is really a superb and artistic explosion ! devil

  • Sven DullahSven Dullah Posts: 7,621

    crosswind said:

    Sven Dullah said:

    ...well, sometimes you just have to embrace the dForce gods...devil

    The Black Rose

    This, is really a superb and artistic explosion ! devil

    Thank yousmiley 

Sign In or Register to comment.