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

  • felisfelis Posts: 4,311
    edited November 2022

    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.

    Post edited by felis on
  • KW001KW001 Posts: 13

    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.

  • Richard HaseltineRichard Haseltine Posts: 100,785
    edited December 2022

    KW001 said:

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

    Post edited by Richard Haseltine on
Sign In or Register to comment.