Boolean Union fails due to CoPlanar is moveFace ok?


Boolean union taking forever, hit esc.
Use MoveFace to pull out the inner Object face which is planar with the knob face,
do so both ends.
Boolean Union works.
then use MoveFace to put the face back to where it should be.

is this OK to do ?

I am making the sides vanish but do they ?

Is MoveFace a fix for Rhino’s failures with Boolean Union ?

Should I instead have not made the inner item overlap into the knob interior by .002inch to get a working boolean, or so I hoped !

but that would then also be co-planar or better described as co-surface (as it wasnt planar).

Is it only planar that is the problem ?

As it was, the interior wasnt the issue as I didnt opt for that, but I get the problem on those two rings, which in design were not to stick out.

Why cant boolean union do things that are designed to be ‘flush’ ?

I try V7 and it also fails. so Rhino just doesnt like unions of two items with a common face.

and trying to design to suit Rhino failing isnt easy or right.

So is this now ok or a time bomb, with a vanished 0.02 side surface shrunk back in at both ends of knob using MoveFace ?

see attached.

Its a lot of fiddle to nuke it and move surfaces, shorten surfaces, trim and join etc. No doubt get naked dots etc.

Nightmare unfolds.
Boolean Union taking forever.3dm (15.7 MB)


Amen to that.
One of these days you will realize the massive amount of time your wasting with your obsession with booleans.

All you have to do is get rid of all the crap getting in the way and join everything
No_Boolean.3dm (962.5 KB)

I would not force boolean union with moving faces.

my suggested dirty and fast workflow
(1) remove the nearly identical surfaces
(2) do a _nonManifoldMerge (dangerous), _cap _mergeAllCoPlanarFaces (_mergeAllFaces in v5 ?)

important: check result
_showEdges for nonmanifold Edges (that might be produced by nonManifoldMerge)

Boolean Union taking forever_tp.3dm (6.8 MB)

and maby rework those areas (other surface / patch layout) my gues this is also mentioned by @jim

I like the idea of two objects fusing together, if it works. Never get over the ’ excitement’ of seeing my work come together.
easy click, as opposed to what can be a tedious trim and join and naked edges happening etc, and a lot more work., 10 secs or 10 hrs.

Sorry if Boolean Union is a bad thing.

Here Jim I see two coloured surfaces inside your fix, drag them out, and it looks like Tom_P, I do a mergeAllfaces to make the front as Tom_P has, and instead it vanishes.

Now why is that ?

Is there something unstable about it ?

maybe rework patch/layout

Took me an entire day to get those vanes as I needed them. and being very careful.
so no chance of a revisit, I am out of time now on all this.

I see your method Tom_P.

Both understood.

So I try to just trim the overlapping brown surface away, I select the knob and use it as a solid object to ‘trim’ and after 10 secs of rotating timer, it goes, I then move to the other end and again do same, and after timer, one small bit of brown goes, the face is made of many triangles/surfaces and each one is doing a trim, rather than the entire object as was ok at the other end.
Here we go, just what I dreaded, trimming bits away. perhaps instead dupEdge and use the result to trim with, and again I have many bits to select to get a dupEdge. I persist and get a circle, use it to trim, and its done, but then when I join surfaces I get a naked edge. here wo go as feared.

Just what is the one click way of trimming the brown overlap, then joining faces. and del the cylindrical surfaces inside). ?

Just why I reach for Union…or Difference.

It was more a case of why does Union dislike such faces, why cant Rhino be made to know whats supposed to happen and make it happen ?

I am sure there are hundreds of fails going on across the world with Union and such faces each day.

and if one uses MoveFace on simple surfaces is it a fix to then pop the face back in or can surfaces not vanish as such, but in this case its contracting a surface as opposed to maling one then vanishing one.


as already said somewhere else - booleans need proper closed intersection curves - only a closed curve can cut out a nice “glue” area to the new neighbour …
so how should 2 surfaces be handled that are nearly, more or less identical , that somehow nearly intersect within tolerance - not forming nice intersection curves … not everthing we see on the screen can be interpreted by this simple algorithm in the way a human perceives it.

the _cap approach has the great advantage, that cap will fail if the opening is not planar within document tolerance. Therefore you will get (hidden) feedback that the input was / the result is precise.

oh well, we all would like it to understand that surfaces that overlap and share a surface need trimming out the overlap.
so I have a go at trim, see how I got on in last post. :frowning:

I would like to see how other progs manage this item.

has V8 been made to cope better, it fails in V7.

Also Tom_P it took ages to open the 3dm and iit warned of something and said redo, so I closed it.
Why and is it safe to use it in my project ?

Jims opened ok though MergeAllfaces nuked the front face above the neck.

I try all over again and get a result, though it also does as Jims, mergeface and the front ring vanishes above the neck.
Knob after trim and join.3dm (3.2 MB)


hard to guess an error message based on “something … redo”. what exactly ?

redo the steps i mentioned on the / your initial file ?

the file opens fine here on a mac version 7 and 8 (just a pop up, that it is a v5 file)
I exported as V5. my system here runs without problems.
But I can not guarantee for anything - you might need to scan the file for viruses …

Hi Tom_P
opened it again in V5 64bit, takes 8 secs to open , black screen in Rhino for that time then it appears, this on my new latest specPC 64Gb DDR4 ram Nvidia 3070 , and other.

the fan picks up and is noisy for that time.

I had a very good Holomark result.


sorry - i have no idea why. - sorry if i can t help further. - going to bed now already late - kind regards from Switzerland - tom

I respect you Steve. You are honest about your addiction to booleans.
You admit you are willing to spend all day setting things up to get the thrill of a boolean.
And then spend another day trying to figure out why the boolean did not work.

But please don’t complain constantly about how long your process takes.
Using the surface modeling tools you should be able to model this in 20 minutes.
Knobx.3dm (1.6 MB)

Getting the job done much faster is not the only advantage to using the surface modeling tools and not even thinking about using booleans or other solid tools in Rhino. The biggest advantage is you will also learn how the solid tools work (or often don’t work). How those solid tools work (or don’t work) behind the scenes will no longer be a big mystery.