Heel, dForce! Heel!
Sevrin
Posts: 6,313
in The Commons
So why is it, explosion or not, that dForce doesn't stop when you hit the cancel button? I'm not talking a few seconds, but up to several minutes. If it explodes, it's particularly annoying, but even without splosions, it can take a while to stop.
Actually, let me rephrase that: Please make dForce stop within a few seconds when you hit the Cancel button. Thanks.
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
© 2026 Daz Productions Inc. All Rights Reserved.
Comments
It probably needs to complete what it is currently computing before it can acknowledge the cancel signal.
and I thought you found a product where there is a d-force highheel, I mean i wouldn't be surprised.
as for your question, yes I think Leana is right, it's the same whn you want to stop a render, it needs a gap in the computing process to let the cancel command get to effect.
Making that a real override would probably cause a lot of DS crashes
Well, with a render, the pause is to let DS save the image to a temp file, so there's an obvious reason. I've actually had to do a hard shut down on DS because the aborted simulation just wouldn't say die.
ok, that's different. not the most frequent d-force user here and if I use it I try to keep my dforce in a separate scene and safe the result to be used. So i hope someone else can jump in and help
damn I wanted the Dforce heel too
was hoping a solution to not having flat shoes with armour
If I am not sure of the dforce working, I usually start with really short simulations. So just enough to see where i5 is going. This might prevent some of the waiting.
If I can speak as a programmer here but also as an engineer with finite element analysis experience. Admittedly I am a very part time hobby programmer, but as one who has been doing so intermittently since 1982, I'd like to give a possible answer.
From my engineering experience of finite element analysis: When doing a finite element analysis (which is what a dForce Simulation is) there are a few stages. 1) create the stiffness matrix, 2) decompose the matrix, 3) calculate the deflections 4) calculate new vertex positions 5) repeat from 1) for each step until finished. Step 2) is always the longest, taking up about 75% of the step time.in a normal finite element analysis.
When programming, if you are going round in a constant loop, I have found that to check for a keyboard/mouse response in a loop of 600 lines of C++ code, if you do it once every 1000 trips round the loop, you double the time taken to do the loop's job - the penalty for keyboard/button message queue checking is severe. Now, how many times does the program go round the loop? I cannot guess at the optimisations used in Simulation, but if a hand matrix were to be created, the matrix would have a height & width 6xnumber of vertices. So, with 100,000 vertices being simulated, the matrix would be 600000 wide by 600000 high (or 360 billion entries) and the computer would have to go once around a decomposition loop for each entry. The optimisation of the matrix should be able to cut the numbers down considerably, by a minimum factor of 1,000, possibly 100,000. However, you are still talking of hundreds of thousands, if not millions of times around the decomposition loop. This suggests the magnitude of the calculation task faced during a Simulation. So, if you put a keyboard/button message queue check once every 1000 loops in a dForce simulation you will turn a 20 minute simulation into a 40 minute simulation.
To avoid the severe time penalty - and I'm guessing - I imagine the programmers doing the 'Simulation' module put a keyboard check in at the end of each analysis step. So, what you are experiencing is the time for stage 2) to finish, and stages 3 & 4 to complete before the keyboard/button entry queue is checked. It's not what anyone wants, but to check more frequently would slow the simulation down hugely.
So, it's conjecture, but I suspect it's just to speed up the simulation, because the pentalty of doing it the other way is significant.
Regards,
Richard.
I work in an industry that does a lot of very intense real time processing but occasionally for safety reasons an operator needs to urgently do something in the UI. That can't be prevented or delayed so a coworker patented a way to prioritize user inputs above anything without killing the timing of it all and that made a huge difference. That was like 20 years ago so that idea is far from new and her patent would be expired (although I don't think there'd be a problem coming up with another way even if it wasn't). I wish any software that blocks access to user controls while it was chugging numbers would implement something like this.
Thanks for the explanation. Doesn't make me less dissatisfied, but maybe less ignorant.
I hope we get a male version...
I can completely understand. When programming I have flirted with the idea of multi-threading (which I know dForce uses to the limit of the machine's capacity) but I suspect I'm too stuck in my ways to manage to cope well with it. This leaves me frustrated as to how slowly my programs go - it's a trade-off that sometimes has no good outcome unless more processor grunt can be thrown at the problem.
Regards,
Richard.
Someone in what passes for armor trying to run in rapidly deflating metal stiletto heels is probably the best mental image I'm going to have all day, tbh.