for me this seams like a bug: (mac os x, rhino 7)
_curveBoolean
adds an unnecessary segment, and that segment is even not tangential:
curve_boolean_bug2.3dm (67.6 KB)
thanks for having a look at it. kind regards. -tom
Hi Tom - I see that - the points move closer together if the tolerance is tighter - basically it includes a tiny segment of the rectangle that is within tolerance of the result. I do not know, but I am not super optimistic that this can ever be truly correct, as it is tolerance based, but I will add it to the ‘heap’.
-Pascal
I see this - interesting phenomenon. @pascal - check this out:
Select the 3 curves, call CurveBoolean, Delete=All, then click inside the figure and Enter. The result is incorrect as you show @Tom_ .
Undo then do the following:
Select the 3 curves, call CurveBoolean, Delete=All, then click OUTSIDE the figure once to select the whole region, then click OUTSIDE the figure again to eliminate that selection, then finally click inside the figure just to get the oval selection and Enter.
The result will be correct.
Hey, I see that - great catch - that suggests there is a fix.
RH-63062 CurveBoolean: differing results
-Pascal
Totally stumbled on it by accident… 
there is another boring workarround:
_trim _join
but the bad thing about above bug is, if you re not aware of it, you will notice it 10 steps later, if things are un precise …
@pascal
…“great catch” - i love that phrase !!!
a lot of funny pictures come in my mind to post here, but afraid it s against the policy of the forum…
any news on this ?
i think the algorithm should check for line - line and line-circle intersections as special case.
see also this topic
i ve started to teach:
“do not use curveBoolean for nearly tangent intersections”
preparing a lecture, again a stumbled about this bug.
@chuck @lowell
(you both names appear on the youtrack…) any news on this topic ?
why do intersect and curveBoolean behave different ?
intersect finds the precise point,
curveBoolean produces a (visible) gab.
curveBoolean_bug.3dm (75.6 KB)
kind regards -tom
Hi Tom. Sorry, that has not been resolved yet. It’s high on the list but something else always seems to jump over it. I took a run at it a while ago with insufficient results. It isn’t quite as easy as it looks. CurveBoolean doesn’t use the intersector directly. I’ll bump it up and take another shot.
@chuck thanks - great to read it s not lost.
did you also look at this topic ? (linked already above)
just curious - why does curveBoolean not “use the intersector directly” ?
I did see that other topic. They’re all related. In order for CurveBoolean to be interactive, it makes polylines out of all the curves and merges them into a graph. Polyline segments that overlap to within tolerance are assigned to the same edge of the graph. Each graph edge knows which polylines use it. The regions are determined from the graph. To go from graph region to parts of the original curves, we have to make a decision when multiple curves use a graph edge that belongs to the region.
Generally the idea is to combine edges that use the same curve where possible. That doesn’t always give the best result and leads to some of the problems you’ve seen. The intersector is called on subdomains of the curves as determined by the graph, rather than on the entire curves. In the case of tangent curves, the overlap of the polylines can be quite large or not where you would expect, since the polyline creation of one curve is not aware of how the polyline was created for the other.
One possible improvement is to use the new-ish fast curve set intersector to break the curves up at those points before creating the polylines. This should eliminate some of the problems. There are other ideas to try as well.
wow - thanks for the explanation.
just thinking / brain storming:
But maybe the polyline-approach is nice for the performance / interaction with the user - and a second approach calculates the final result based on the users klick-points and initial curves? (could be even prepared in the background / second thread / while the “slow” user is active…
and/or the polyline needs to remember the initial tangent / normal per vertex - then overlapping per segement is not only defined by distance but also by the tangent match of both points.
(i know that the basic polyine structure can not store those values…)…
well i ll look forward to see the result, what ever solve the issue. thanks - kind regards -tom
Hi Tom,
In the file you provided, there is another (red) curve overlapping the purple one. Once I remove that I get a clean result without the small segments you are seeing, in both V7 and V8
Command: '_CurveBoolean
Command: _PointsOn
Command: _SelPt
17 curve points added to selection.Dear Gijs
Thanks for having a closer look at this.
to reproduce:
right click on Layer constr / purple
→ 6 curves added to selection
_curveBoolean
_allRegions
click once to remove the bulky circle
enter
_pointsOn
will show the micro-edge results…
… wait i record it…
voila
mac os x Version 7 (7.28.23058.03002, 2023-02-27)
I see this now, apparently order matters. Trying the same without preselecting gives another result, and once I window cross select from upper right to lower left, the result is the result you would expect.
This is a known issue listed as RH-7312 result depends on order
I’ve added this thread and file, thanks