CurveBoolean vs. Intersect and Split

Hi Mitch,
this post is old but could be useful to answer to your question.
If I make a rectangle and cut it with two circles to obtain a buttonhole (don’t know if this is the correct name) Curve Boolean is less accurate than split.

Looking near arc end you can see that we have more than one control point

If I split the rectangle with the circles and after that the circles with the two middle lines I obtain a better result.

Looking closer


Hmm, interesting. I have never noticed this.

I see something similar here, except sometimes - I guess depending on how you pick the parts, the three control point locations could also be in the middle of the arc parts - where they intersect the short side of the rectangle. If you look at it closely, it leaves a tiny line segment in there. Sometimes I get 4 extra cps (total of 16), sometimes I get 8 (total of 20).

I suspect this is due to some sort of artificial loosening of the intersection tolerance in CurveBoolean somehow, because if I tighten the file tolerance by an order of magnitude, CurveBoolean gives me a clean result with the same control points as split/trim/join. I can’t remember who is responsible for CurveBoolean - @chuck or @lowell ?

CrvBoolExample.3dm (312.6 KB)

Yes, probably to avoid problems when a big quantity of curves are selected.
Would be better if the command ask to loose the tolerance in case the selection has a lot of intersections.

1 Like

Got that, thanks…



Have you tried with and without the “Planar” setting? Also, try using “Set XYZ coordinates” to make the (already) flat curves flat before the Boolean operation.

As you suggested, I’ve tried the Planar setting On/Off and flatting the curves to 0.0.0 but the issue is still there.
Curve boolean works well in most of the cases but the buttonhole is one of the exceptions that I know that is better to avoid.

I can’t find the original topic where I reported this particular bug for Rhino 6 several years ago, so I will post here instead. This bug is still doing weird things in my Rhino 7, so I’m literally forced to not use it at all since I have the program.

Here is another example about the inaccurate results that the “CurveBoolean” tool produces. It shows why you don’t want to rely on “CurveBoolean” for working on important projects. I suggest to use “Trim” or “Split” instead, followed by “Join”.
The “CurveBoolean” tool destroys the original shape of the input curves, because it uses loose tolerances for the boolean operation. As a result, the true arcs and circles no longer have a constant radius, which is critical in many industries. The resulting variable radius also makes it impossible to snap to the center of the now destroyed arcs and circles.

After checking the log from Pascal’s link above, it looks like back in 2022 the developers decided to not fix this bug in Rhino 7.

1 Like

it is fixed in v8?

No, the bug is still active in both, Rhino 7 and Rhino 8.


Thanks for the update.
At the moment i don’t even check if things are working better… I run SimplifyCrv after each BooleanCrv and if there are internal holes some scripts that recognize circles and rebuild them with the correct diameter (with a .00 tolerance).