BUG: Intersect command repeatably inconsistent, incorrect results

In everyday modeling I frequently need to find simple intersections between two surfaces. An ongoing theme on these fora is complaints that the Intersect command failed to find an intersection, or only found part of the expected result. In my experimentation with this bug I discovered, quite by accident, that the results could be hit-and-miss depending on prior manipulations of the objects to be intersected. For example, an intersection may not be found between two obviously intersecting surfaces, but after a slight common rotation of both surfaces the Intersect command would, indeed, find an intersection, or parts thereof. This seemed odd, so I wrote a little script to investigate multiple iterations of the rotation command.

Eventually, I realized that a rotation pair that returned the surfaces to their original intended orientation was equally effective at inducing the intermittent behavior of the Intersect command. I cleaned up the script so the rotation operations were hidden from view and proceeded to experiment. What I discovered is that, given enough tries, the Intersect command could, indeed, succeed in finding the intersection in my simple test case model! (I refuse to entertain the suggestion that I “should not” build my surface models with surfaces that are nearly tangent at intersections.)

More interestingly, observed failures of the Intersect command included “complete” intersection space curves that were not contained on either of the two input surfaces, but bending freely through space. “That’s not right,” I said to myself, “I should tell McNeel.”

So here it is: a pair of button scripts that can be assigned to the left and right mouse click events of a button. I call my button “Intersection Bug.” The right click event starts a new, blank, default Rhino drawing and creates two orthogonal G2 fillets, and tries the Intersect command. The left click event deletes any intersections found and then rotates these two surfaces +45° then -45° so as to return them to their original orientation and tries the Intersect command again.

The results are completely repeatable and startling: after left-clicking the button twice, the Intersect command finds an “intersection” curve that is completely divorced from either input surface except at it’s extreme endpoints, and a second intersection point at the upper boundary where the two surfaces are coincident and nearly tangent. This is not only not expected, it is almost completely incorrect.

Further left-clicks of the button yield some repeats of the same incorrect result, repeats of a second entirely different incorrect space curve that is also completely divorced from the input surfaces except at the endpoints, a few repeats of a partial result that only proceeds to the midpoint of the surfaces’ intersection, and, finally, on invocation number 12, a correct intersection is found. Likewise on invocation number 13, the correct intersection is again found. But it is not repeatable after that! Invocation number 15 yields the “last” time that the Intersect command finds any result at all as a result of the +45°/-45° rotation pair, although I have only manually tested through 200(!) button-clicks.

Stranger still, changing the rotation/anti-rotation pair to +1°/-1° gives a completely different sequence of incorrect results, at a higher frequency of incidence, as one might predict from considerations of rounding and truncation errors, etc., but ultimately this new rotation/anti-rotation pair also finds the “correct” intersection curve – at invocation FIFTY! And again at invocations 102, 129, 185, 216…!

What the heck static function call buried within the Intersect command is weirdly caching data in the background and causing the same function to yield different results on subsequent invocations? What is it about the Intersect command that is allowing it to yield clearly incorrect results MOST of the time in such a simple case as the orthogonal intersection of two native G2 fillets, yet find the correct result on rare occasions?

I’m not a practiced and intrepid code sleuth so I leave it to the experts to find and fix this problem. All I am interested in is having consistent, correct, and repeatable behavior from my software tools. And this is not that.


Intersection Bug Button.txt (1.1 KB)

2 Likes

Perhaps you could provide an example .3dm file with geometry which causes these problems

The script I previously uploaded produces the geometry.

“So here it is: a pair of button scripts that can be assigned to the left and right mouse click events of a button. I call my button “Intersection Bug.” The right click event starts a new, blank, default Rhino drawing and creates two orthogonal G2 fillets, and tries the Intersect command. The left click event deletes any intersections found and then rotates these two surfaces +45° then -45° so as to return them to their original orientation and tries the Intersect command again.”

Intersection Bug Button.txt (1.1 KB)

I see that, thanks.
RH-65650 SSX: no intersection
-Pascal

1 Like

This script can solve this type of intersection:
https://github.com/CADacombs/rhinopython/blob/master/xIntersection_surfaceSurface_PullTween.py

Nice. I wonder why this kind of functionality isn’t part of the native codebase.