MergeAllFaces - escape

Please allow us to escape from MergeAllFaces when Rhino hangs on it (as is often the case with all but the simplest of objects).

Also, in general, a user timeout for this kind of command would be good, if it doesn’t complete within x seconds, that it gives up.

Thanks, --Mitch


+1 and add a counter that shows us the progress.

1 Like

Thanks, added to the pile-


Hello Pascal,

868 days later…

The youtrack link goes to nowhere.

It is really necessary to be able to cancel the command.
This applies to several other commands, e.g. the booleans.

In case of _MergeAllFaces, a major speed improvement is also welcome.
Very welcome.


1 Like

oh yeah - plus one on that please.

1766 days later… this is probably the most common command that freezes Rhino over here.
Most of the time waiting for 20-30 minutes saves the work and eventually ends, but could we please have ability to ESC ?
YT link goes nowhere…

Thanks to waiting for it now, I have time to write this post. It’s dangerous…


Hi Jarek - the YT link does go somewhere but you didn’t have access - until now.
@rajaa put it on the 7.x list some number of days ago.

Waiting for an operation while being unsure if it works or not is really no good.
At least a progress should be displayed.
And of course a chance to cancel.

Too bad the YT item is prospected for V7.

Thanks Wim, 7.x is not very exciting outlook for this… considering how long standing of a wish that is (or generally being able to ESC from pretty much any command) and how many/how often users complain about this.


Hi all,
Sorry for late reply, I was out on vacation.
We have done few important improvements to MergeAllFaces that solved bugs that caused the command hang or give inaccurate results. If you have examples or relatively simple geometry and is taking unreasonable time to solve, then I’d much appreciate to see those. Just make sure to test with the latest release.
As for cancelling MergeAllFaces, I’ll look into the feasibility to implement for Rhino 6.

hi Rajaa,

thanks for the update! Apart from the occasional producing bad objects or just taking very long on objects with ~100+ surfaces, the command works well. It’s mainly the freeze and inability to escape that is problematic…
Are the improvements in V6 latest SR, or V7 WIP ?



All improvements are in V6. I fixed a freeze bug, so I’ll be interested to see examples that freeze.

Taking long time problem can be resolved with an escape, but if it is in a loop somewhere, escape will not help. If I recall right, implementing an escape is complicated because of how the command is structured, especially if attempt to return partial result. I’ll look into it nonetheless.

In terms of speed, I tried to have a shot at processing multiple co-planar faces at once (create one big boundary and one plane), but had out of tolerance edges that created bad objects in some cases. The problem was that while adjacent faces were coplanar within tolerance, faces that are farther apart accumulate enough wiggle that pushes some edges out of tolerance relative to the plane. This is why I reverted to the original exhaustive solution of solving for 2 faces at a time. I think it is on @chuck list in V7 to look into possible speed optimization of MergeAllFaces.

hi Rajaa, thanks for the in-depth information. FYI - I think it would be fine to not retain partial result when ESC is pressed… Sometimes its just not worth the wait and we can take another route to get the result rather than waiting for the command to complete; or at least save before running it and not being stressed about losing work : )


1 Like

6 years later… Yet another of regular Rhino freezes of MergeAllFaces with no way to Escape the command. Is it difficult to implement or just seems not important?

Hi Jarek -

I understand that you refer to the date RH-28923 was created but it’s less than a year since Rajaa explained that improvements have been made and that she clearly stated that she was interested in seeing examples that cause trouble. Have you provided samples of such within the past year?

Hi Wim,

Yes, I was referring to the original request of allowing ESC-canceling of the command, or possibly even seeing some completion progress. That was the original request of this topic and something IMHO still needed for this any many other Rhino commands.

The wish still stands, regardless of the improvements made to the command itself or any sample to be provided.

Having said that, I have to gladly admit that after some testing this command works a lot better and faster in WIP compared to V6. We do not work in WIP on any production projects due to potential stability risk, so the recent freeze happened in V6. The same element that froze V6 for a few hours and then forced me to kill Rhino (could not afford waiting till morning, even though from my experience it eventually would come around), in V7 got processed in a few seconds. @rajaa - thank you for this great performance improvement.
Here is another example: (1.1 MB)
In V6 Rhino freezes (for a while at least), In V7 over here it completed in about 2 minutes. I can easily imagine using this command on much more complex pieces of geometry, so the ability to ESC-out would still be helpful.



On my computer, born in 2010 :slightly_smiling_face::
V6 - 1 minute 4 seconds
V7 - 58 seconds

Don’t see much difference but V6 is actually faster here V6: ~53 sec. ; V7 ~57sec. (dual xeon 2.3GHz usage 2.5%)