At times, I face a strange curve self-intersecting exception that occurs with the same curve in one location but not in another. For instance, with this plain shape originally created at the 0 XY world origin, there was no self-intersecting. However, when moving the same shape to a different location, self-intersecting can occur or may not. In this example, the shape is located at the spot where self-intersecting occurs, but shifting it a little to another position makes the self-intersecting disappear.
Yes there are solutions, but it occurs often and without understandable reasons, more over the issue severely affects on the productivity of gh “boundary surface” component. Shape.3dm (3.5 MB)
Thank you @11165 for your reply, but if you move the shape a little bit, the intersection disappears. The question is, why does the self-intersecting happen at some positions and not others with the same curve?"
which makes it impossible for rhino to determine if this small arc intersect with its nearby line.
sometimes it may calculate as intersect, sometimes not.
operation in this number range would be absolutely unstable and has no meanings.
Thank you, I have got the idea of what the reason can be. I have uploaded the definition, which is pretty simple and should not cause self-intersection, but anyway, some components do it…
The real issue is that the small arc should not be introduced by Grasshopper in the first place - there is no need for it.
You can bake the results of the last three gh building components (Connect Ends, Region Union and Fillet) and, in Rhino, analyse the geometry at each stage. You will find that the first creates 12 segments as you would expect (3 x 4), the second creates 18 segments (3 x 6) as you would expect and the third creates 25, ie one more than the 24 expected (3 x 8). The extra segment is the micro arc referred to above.
So this extra curve is introduced by the Fillet component and it occurs at the opposite end of a curve to the end affected by the fillet. I can see no reason to recalculate the unaffected end - it should surely simply copy the original position (which coincides with the end of the next segment, which is of course not acted on by the fillet). To my mind this is the result of a bug in the gh Fillet component. (? @DavidRutten)
Building the curves in Rhino demonstrates that Rhino’s fillet results in 24 segments - i.e. does not exhibit the same error.