A dream of mine is for Rhino to abort any Command by simply hitting the “Esc” key. I have often started a Command and then realize that there was a better way to perform the task. Some Commands will let you Esc to cancel, but some others that really crunch the math will not. I have a DREAM…
The “Math Crunchers” as you called them try to set a balance for how often they come up for air and see if you tapped the Escape key.
The more often they check, the slower the command finishes because it’s being interrupted so many times and so often.
If all command could bail out quickly, these “Math Crunchers” would run much more slowly all the time.
The explanation of why you can’t escape doesn’t solve my Dream. As an example, when I want to explode a mesh model when the file is in the 10,000,000 KB range it can take 10 or 15 minutes to think about it. Once you hit enter on the Explode Command you’re screwed until it quits or you need to shut down the program to make it stop and lose your prior work. Just in case you’re wondering about my horse power… custom BOXX with Nvidia Quadro RTX5000 16GB GDDR6 X2 (1-render, 1-display) GPU, and 192GB DDR3-1333 REG ECC RAM (water cooled)…
Well, John explained why this is. How much slower do you want everything to be so that it can break faster? None of your RAM or GPUs are going to help this, it’s basically down to single-thread performance.
I agree 100% that there should be no commands that just freeze Rhino with no way to escape. This is the biggest productivity loss even for experienced users IMHO. It’s understandable that the math crunch would take a hit, but is there really no way to address this or just it’s considered not a high priority? Maybe check every 5 seconds or 10 seconds even, if the user holds Esc, or work on some better solution. That part is one of Rhino’s weakes points and one of the most frustrating ones.
There are numerous requests for multiple commands that are particularily prone to these freezes, but they have been ignored or low priority for years, like this one:
Please make MeshOutline escape-able! - Serengeti (Rhino WIP) - McNeel Forum
–jarek
Finally, someone that understands. Most comments so far have been in the lane of “shut up and except it”. There are a lot of smart people out there that could solve this issue, but Jarek is most likely correct in that it’s a low priority for Rhino and probably to those that work by the hour, not by their performance. I deal with several GIG files and this is a major problem.
Jim is probably a by the hour dude, not because his performance keeps him in the race. Speed is more important to completing the task than it being time for my next cup of coffee and a scone.
No, I just know enough about programming to know it’s not as simple as you think it is.
I never said anything about it being simple to do. I just said it was a dream, that should lead you to surmise that I don’t think it’s simple to do, just a desire. If people are never pushed to do new things they turn into just engineers that only accept the proven and existing, not designers that can image a better world. I started out at Ford in '77 and learned all about people that say “it hasn’t been done before, so it can’t be done”… bull crap!
Steady on lads, steady on…
Understood Fred… good call. I’m at fault on this one.
Regardless, let’s bring some of that Cancel Culture to all Rhino commands, shall we??
Cancelling is built in to all the commands that need it. It has been adjusted based on examples we received and tried ot accomodate.
To further fine tune this we will need specific examples, with 3dm files and the instructions to follow to repeat the issue.
We will also need the SystemInfo for your systems.
Then maybe we can do something about it.
Without those specific examples, we’re all barking at the moon.
John - if this was the case we would not be posting here. The last thing we want to waste time on, apart for waiting for commands that froze, is to bring up issues just for a sake of doing it. I would think users can tell when then need something to work better or be able to escape. MeshOutline is one of these commands…not to look too far. On YT there are a lot of open tickets for these (like BoxEdit, Explode…) Typically the case is, well, if you do it on complex enough set of objects the commands just take very long or freeze Rhino permanently, and often we would prefer to cancel and move on instead of waiting for the result. Sometimes it is accidental. Seems like requesting sample files and SysInfo to add “Cancel/Esc” to commands is an overkill, sounds more like an excuse that these requests are sitting there for more than half decade.
I’m going to show my complete lack of modern programming knowledge here but maybe this will trigger some thoughts. As failure to abort on Esc seems to occur when big operations are in progress (we can add Intersect, Boolean Diff, sometimes Boolean Split, to the list), it seems that Rhino literally grinds to a halt, finally becoming deaf to all interrupt requests. Presumably, the program is looping through a set of subroutines, storing the output of each iteration until it completes a large repetitive operation. Might it be possible to clock the loop, such that Rhino gets an early heads up that it is going to run out of steam (e.g., time to complete the first 100 loops versus time to complete 100 loops after the 1000th)? It could then offer the user a chance to abort before it reaches the stage of not being able to accept any input, internal or external.
One last comment… In my dream of Esc for any command. JC1’s comment about “clock the loop” caused me to remember something. I have talked to someone at SIGGRAPH a few years ago and she said that it isn’t impossible to allow for an exit from any command that would cause a clock-back to just before the initiation of the command. As I recall she suggested a two key something like Esc-Ctrl… maybe. I explained this conversation as best I understand the mysteries that go on inside my computer, that’s not a lot. Because I’m not a programmer and only know how to break things, I’m depending on my recall of the conversation and could be totally full of it and got it all wrong. This Esc has been a glitch for me for a really long time.
This argument is not convincing in the age of multi-core processors. The most likely cause of this problem is that Rhino rarely uses more than one processor core.
Please provide repeatable examples so we can find the time problems and fix them.
To quote a meme, “that’s not how that works, that’s not how any of this works.”