dForce has no Cancel button, why?
Zilvergrafix
Posts: 1,385
Hi, this is me...again.
to the point, I was trying to simulate a cloth, but the infinite quantity of "springs" being created and the long long and slow progress bar convinced me to Cancel the process,
but bad news, there is no Cancel Button, in such case I had to KILL the entire software, no problem at all because I have the rule of gold to "Save before" in many ways of my 3D life.
question is: WHY, why does not have a Cancel option?, tech savvy people are invited to answer, please. 
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Probably for the same reason you cannot cancel asset loading, it would be complicated to code and they would rather spend their time adding new 'features'.
The Cancel button will appear after it has finished its calculatioins and the simulation has started
well maybe you're right.
That's what I don't want, I would like to cancel on preCalculations because sometimes there are clothes that converted to dforce takes a long time doing calculations (springs they call), is ok in many cases but when I do a mistake on complex cloth the calcs takes more than 1 HOUR.
Dforce was a new feature once
This has been talked about before in depth. A programmer (not from daz3d) explained that adding an input would severely hamper the simulation.
I suspect thata dding event checks to the process there would have an unacceptable impact on performance - it's a lot of what seem likely to be very short loops checking the edge lengths, so the extra steps might very well double or more the time taken.
another theory: they didn't spend the effort of putting a cancel button there, because that step is very very fast.
It's only when it logs 100MB of "rest length < collision offset" that it becomes very very slow.
A workaround for the issue is to set 'collision offset' to a very low number like 0.000001. I didn't notice any visible issues with that, and the million errors go away.
Because they only handle the "cancel" when all the spring messages have been output and, at that point, the dialog window disappears (a pet peeve of mine; please, if there are spring length issues offer a dialog to fix them...)
dForce also only responds to a cancel during the simulation at intervals of one frame so far as I can determine. A work round for the latter is to set the FPS to the maximum and reduce the number of sub-frames a corresponding amount but the FPS maximum is quite small and care has to be taken not to mess with gravity. This should be fixed as well; waiting for an explosion to finish (well, reach the next frame) is unbelievably tedious.
I find the issue is an issue for pretty much any item where the PA has left the collision offset as 0.2. While it does eliminate the spring messages setting the collision offset to 0, or something close enough, a value of 0.1 (1mm) is normally enough to reduce the time for the messages. The real fix, which I almost always do, is to cancel ASAP after the spring messages, open the log file, and iteratively reduce the offsets of the surfaces to the values reported in the messages. It normally takes me between 3 and 10 attempts to start the simulation before I get everything fixed.
BTW that whole spring dialog is an utter waste of time and effort. The messages fly past far to fast to be read and take much too long to output; why bother since most of the time goes outputing them to the dialog! What should happen is to do what I do iteratively within DAZStudio; solving the optimal spring offsets is normally trivial (smallest for each surface) and, when the problems come from colliding surfaces, is soluble analytically within DAZ. I can't solve it outside DAZ because DAZ doesn't record which pairs of surfaces collide. Actually DAZ doesn't record the surface in the log file at all; I work round that by setting a different collision offset (0.10, 0.11, 0.12 etc) on each surface. The default is also visually unattractive; I can see the 2mm gap in many renders! 1mm is still a bit big but normally a lot better.
It would be trivial to not output any messages but pop up a dialog with options to continue, cancel or solve and restart. The latter is a little more work, but even a log of the shortest spring on each pair of surfaces would be sufficient for me to avoid lots of tedious eyeballing of the log (the shortest spring length is currently for all the springs across all the garments+hair).
@stephenschoon, @Platnumk, @WendyLuvsCats, @Paintbox, @RichardHaseltine, @cajhin, @jbowler: thanks for your information, going to reproduce the same issue with that cloth (Vanese Marquise Top) and changing values based on your tips and advices.
if all goes better maybe I will a video adressing the issue.
The messages are coming out once per spring then something in DAZ is waiting for them all to come out before popping up the main dialog. I trust the code which is checking is not running in the main loop but if it is your comment doesn't apply.
The way I solve this problem (e.g. interrupting an image scaling operation mid-image) is by using QAtomicInt as an event count; the loop checks the value of the integer regularly and if it changes the loop aborts. An atomic bool is sufficient in this case but an integer is what Qt provides. IRC Qt4 had something similar; some stuff changed but there is a forward compatible approach in Qt4. It's important to use an atomic variable not a mutex because CPUs (well, since the original ARM3a; mid '80s) implement non-blocking atomic operations which can't hang, unlike mutices.
Not a programmer but how about a check before the calculations start and a warning that the polygon count might be excessive (Cancel or Continue?)?
The number of messages is useful - if there are a lot of too short edges then the simulation will be slow and possibly prone to explosion (because the offset wants to stretch the edges to the minimum value which puts extra energy into the edge which dForce has to diffuse). However, it isn't ncessarily a bug - a few over-short edges can be acceptable, or they may be edges that will not actually factor into the simulation - so automatically adjsuting the offset is not desirable. The messages are written to the log, for reference.
Sorry Richard, I disagree with that. I never had an issue with clothing (superfast SSD, I don't care about 1000 messages).
When I was learning dForce hair though, I occasionally had cases where it was hanging for 5 minutes, writing ~1.000.000 lines to a 130MB logfile.
Nobody's gonna read that...
would have spared me an hour of mild annoyance. (no idea why it was SO many messages, it's not like most of the hair was clinging to the skin or anything like that).
But thanks for the explanation, I never really understood what's going on with that warning.
The long springing process was caused by this chain geometry:
When only need to simulate the shirt above the corset, no need to the corset being simulate...neither chains BUT never got realized that no cancel button is on the pre processing...duh!
and yes I know how to apply dforce weight map node but was my ultimate option..i hate weight mapping, I do a lot of that on rigging...pita.
and the corset is not welded geometry, it was broken in pieces after run simulation.
I did a radical solution when the starting of the calcs for the "springing" (is that right) was done and no way to get back...eliminating geometry!, applying a second wardrobe and done!
What I meant was that perhaps it is possible for the dForce code to include something that checks for heavy polygon models. I don't know how that applies to your chain. Another option might be to decimate the mesh either by using the DAZ Decimate Plugin or Blender?
another most simple, a time counter, when time of running goes more than 3-4 minutes then ask to cancel or continue, dunno, I am not a programmer and only can dream.
I completely agree, if I just see three or four short edges I'm prepared to trust the PA to have actually tested it. Yet there are a couple of problems with your argument:
Sorry to whine, but I believe this is easily soluble without challenging any religous convictions. More choice is good, not allowing a long operation to be cancelled is bad. Cancelling a render works just fine these days, a dForce simulation is an analog of a rendering operation and it should be cancellable in the same time frame.
There was an email survey a while back about whether dForce garments should also be conforming. I believe (religious conviction) that a garment should be one or the other.
I assume it is this product:
https://www.daz3d.com/vanessa-marquise-outfit-for-genesis-3-female-s
I don't think those are chains, I suspect they are pieces of cloth with chain painted on them (I don't have the product). The way to find out is to swap the viewport to "smooth shaded", this shows the actual surfaces that dForce really uses. The problem that I've encountered trying to add dForce to older garments is that the pieces of cloth are simply not sewed together, so they fly apart, or drop apart, when dForce is applied.
the chains have geometry, when I realized that it was too late to react since looking for the cancel button I realized that it does not exist in the pre process,
I agree with you with looking like painted, on the promos of the product looks like painted.
Yes!, that's how thing should be !
This is the correct answer.
Qt applications use what is called "Cooperative Multi-tasking". This means in order to have a responsive GUI during a long calculation, the routine that is doing the calculations has to cede control back to the application so it can continue running its event loop, i.e. responding to button clicks, etc... via a Qt function called QApplication::processEvents().
The problem, and most likely why this wasn't done, is outside of a model dialog box, there's no way to control what the application might do, once control is ceded back to it. The GUI event loop is slow compared to a tight loop calculating something, even when there are no GUI events to service, and it invalidates all the data that it had cached. Worse, if the calculating routine and the application don't know enough about each other, the application could then try to grab a resource that the calculating routine had gotten exclusive access to and has not released: the program will freeze.
And besides, there's no foolproof way of knowing, at program design time, when to call processEvents(). To often and it will kill performance. To seldom, and the application still seems unresponsive.
Qt is a great framework, but so that it will run on everything from PCs to the attitude indicator on a B-2 Bomber, to the temp gauge on your smart fridge, they had to choose the lowest common denominator, i.e. processors and OSes that don't even support threads at all. Unfortunately, that lowest common denominator is what we get for everyone: cooperative multitasking.
I did a video with long time to wait for spring process, maybe in that way can understand the initial purpose of this thread.
This may have been true once, however at least in the version Daz uses (4.8 I believe) and later versions true asynchronously running threads are supported. It's easy to see from the Windows task manager that DAZStudio routinely uses at least two CPUs at once and in the 4.14 beta discussion of the hang-on-exit bug reference was made to the use of QThreadPool by plug-ins.
Anyway, my argument was based on the assumption that the spring checking takes place in a separate thread because it takes significant time; interrupting a tight loop is slightly more challenging but that's why C++ has a "volatile" keyword, QAtomicInt is just a clean way of doing the same thing! If the dialog is in the UI thread I simply can't see any excuse for the absence of a cancel button; { bool cancel(false); tight_loop(&cancel); }
Hi @jbowler,
The volatile keyword is useless on multicore systems, but that's another conversation :)
You bring up good points. I didn't mean to imply that Qt didn't support threads, just that the GUI is single threaded. Ironically, I use QThread to implement the cancel button in Sagan...
If Qt's async methods are being used elsewhere, then neither can I think of why there wouldn't be a cancel button; I was trying to give the benefit of the doubt :) Maybe that code is developed by a third party and so Daz can't set any flag to cancel that the computational routine knows to look for and respect? Maybe to avoid the hassle of making the process non-reentrant?
Edit: I had overlooked that the routine outputs a lot of text during the computation. So either it's in a thread with some eloborate communication method, or it's already calling processEvents(). I have no idea why there is no cancel button then... I think the most likely answer is that they just didn't implement one because... reasons.