Boolean union fails, but why?

Hi all,

I have a few closed polysurfaces, all the same.
Basically cylinders with a tapered bottom.

NoBool.3dm (230.0 KB)

The green ones do work fine, but the red one fails.
From what I see it should work fine, at least I don’t see the reason why it should fail.

(In V6 WIP, it is the same)



Union the Green ones.
Then run Intersect between the Red and green.
Invert the selection and inspect the curves.

It looks like how the curves of intersection are overlapping, the expected curve segment joining is not right for the Boolean.

Explode the curves and Join them together so they fit with what you expect.
Then Trim and Join to get your desired result.


I checked the intersection curve before.
What exactly is wrong with it?

I wonder why the green ones work, they are exactly the same as the red ones.
Also it works with slightly other distances…


Sorry, I thought I explained.
"…the expected curve segment joining is not right…"

I think Rhino is getting it wrong.

What I gave you was why I think that and how to get around it.

I have not tried it in V6 yet. If it’s wrong there, I’ll add a bug report.
It will not be fixed in V5.

Try in V6.
Seems the bug report is the thing to do…



Independent of Rhino’s limitation in this case, I don’t understand why you are modeling that shape in this way. It makes a good example to highlight the limitations of the current statue of the tools, but what are you modeling and why is this the approach being used to make that shape?

In exploring this, I found a curiosity I don’t understand:
I deleted your green objects, then Exploded the red polysurface and joined it again.
Then I used Array to made a new row of 5 polysurfaces 3 mm apart like the original green ones.

This group of polysurfaces Boolean as expected.
So far, I can’t figure out why your green ones don’t work.


Because I don’t have a better idea.
Do you have?

The goal is to show the traces of a cutting tool.

Oh, that’s not good news.
As we don’t know why, then we can assume it is a bug, right?

If this is really a limitation and not a bug, then it’s no good.
Other software bools this with no problem…

Now what is it:

  • user’s ignorance?
  • stupid expectations?
  • limitation?
  • bug?


@Charles: Lose the tone.
I understand the frustration.
It isn’t helpful in figuring out the problem.

At this point I do suspect a bug but I don’t think it is in the Boolean specifically.

I described how I replace your objects using your own, that did not exhibit the Boolean problem. So far I can’t figure out any difference between your original red polysurfaces and the new ones I created by Arraying your green one.

Precisely, how did you create the red ones?
My guess is there may be a bug in the tools you used to create the red objects.
As you know, to fix a problems, we have to be able to repeat it.

I just narrowed down the problem a bit more.

I deleted the polysurface next to the red one, the copied the next on over to replace it using the Center osnap between two other polysurfaces to keep the original spacing.

This group with the single replaced polysurface does Union as expected with no other changes.

That narrows down the problem to that polysurface.

Next, I isolated it, Exploded it, ran RebuildEdges on it’s surfaces, and Joined them back together. This “cleaned up” polysurface also worked fine for the Union.

How was that left most green polysurface created?

Which tone are you talking about?
In any case: John, I apologize, sorry - I think the ‘tone’ is just a misunderstanding.
On the other hand, I understand your frustration.

In the beginning, there is a profile curve.
This curve was used with Revolve.
ArrayLinear created all copies, regardless which color.
The red color was only assigned to show the offending object, no other changes.

The same main problem occurs with other similar geometry as well.

John, I tried ‘everything’:

  • a row of objects, let’s say 20, and begin to bool beginning at the other end
  • rotate all by 90°
  • other cplane
  • scale by 10, 100
  • rotate by an arbitrary angle
  • other geometry
  • bool in groups
  • bool one after the other
  • playing with tolerance settings
  • without the upper flat surface
  • copy one by one, not using linear array
  • etc.
  • etc.


Edit: Do you know a good workaround to at least get the desired geometry?

That’s very strange.
I gave you two ways I got your model to work.

Try these:

Delete the green one closest to the red.
Copy one of the green ones into the space left by the on you deleted.
Select them all and click BooleanUnion.
That Unions correctly for me.

Undo back to the original, then:
Select the green one closest to the red.
Explode it.
Run RebuildEdges at default tolerance.
Join the results.
Select them all and click BooleanUnion.
That Unions for me too.

For whatever reason, it seems there is a problem with the first green one.

I’m at home on my Mac.
On Tuesday when I’m back in the office, I’ll try it in V6.
If it fails there, I’ll see if my work-around’s work and get it bundled up for the developers.

Thank you, understood.

The posted model is an example only.
So the methods to get things done works in this case.

There will be different geometry to work with.
The mentioned workarounds do not work with this other geometry.


Note that fixes to the code based on a specific example will not (likely / necessarily / always) fix problems in other situations. If you have other situations that fail, you will have to post these as well.

Wim, that’s easy:
NoBool2.3dm (294.2 KB)

Not exactly the same, just an experiment:
NoBool3.3dm (329.5 KB)

Example with 4 objects only:
NoBool4.3dm (110.0 KB)


hey Charles i dont even want to say how much time i spent on one of your examples and did not succeed i had multiple approaches but always ended up that surfaces did not want to work with comments like non manifold edges found.

you can try with the script placed in this thread Split curves at every intersection it helps you to split each surface with each other, i gave up on it because my computer is about 7 years old, maybe you have a quicker one and can succeed. it will not give up so easy i guess but you have to be patient and let it work through because having appropriate splits is the only thing which still can help you there i believe. after that you have to delete all the unwanted surfaces and join it carefully together. its still a lot of work and no guarantee.

booleans function may also have problems determining which surface shall be joined together with which because you have them stack into each other so much that some surfaces get split over several other surfaces and rejoined at completely different intersections… i dont want to make any theories but thats tough stuff. to cascade shapes intoo each other having them touch on one curve only till they get rejoined is always pushing booleans to its limits, i would suggest finding a better workflow for this.

If that is your objective why not just draw the centerline of the toolpath and offset it on both sides by the tool radius. You can then add a 180 degree arc on each end and use hatch to indicate the area that has been machined.

Thanks for sending these. I’ll put them on the list and see if I can fix them next time I work on booleans.

The problem seems to be caused by the way we are handling the seams on the revolved caps. In your first two examples, NoBool and NoBool2, if you explode, delete everything but the cylinders, and cap, then you get the same shapes and can boolean the result in V6 (didn’t try V5).

they are tapered going to the inside towards one point on the low side, just recapping will not do they really cascade into each other.

I see that now, thanks. Ignore my comment about that.