Intersection command results in a different outcome w/ nearly identical conditions. (BUG?)

Green is my selection color.
The intersection result was moved over for clarity.
Original file attached.

test.3dm (1.3 MB)

Hi Asterisk- I see that, I do not have an explanation yet- thanks for sending this.

@Asterisk- the polyline points are microscopically off in the set on the right.

ON_Point: (3756.1597824068244, -7341.3390402399928, 1.2908986754750409e-13)

ON_Point: (3756.1597824068476, -7341.3390402413761, 1.2908986754750409e-13)

I don’t know if that should change the output of Intersect, given the file tolerance though- I’ll ask… @GregArden, what do you think?


The tolerance for parts of curves to be overlapping is much tighter than file tolerance. These segments are 10^-9 to 10^-11 apart on one end and matched up on the other end so I say those curves are diverging instead of overlapping. A mirror operation or a some other sequence of accurate modeling steps should not introduced that large of an error.
Greg Arden

This wasn’t mirrored. The smaller curves were moved to the big curves by Rhino.ObjectGripLocations. Same code lines were applied in both cases. Also, check this thread out, maybe it has something to do with this case.

Hmm, I don’t get this really… that distance is so tiny, I don’t see why it is considered different by the intersector… Also, if they are considered “diverging”, there should only be one point given for the intersection, not two… ??


I’m gonna post more findings here.
Again, the polysurface isn’t unrolled into Z=0. Why?
Even more, the surface corners aren’t technically in the same plane, hence added control points in DupBorder’ed curve. Why? It makes my script fail rudely. :stuck_out_tongue:

See attached.

All original surfaces of the polysurface are flat (planar).
Untitled.3dm (119.0 KB)

Dunno, looks like it’s on 0 to me - at least to 8 decimal points. Don’t actually know why UnrollSrf actually changed the degree of the trim for the one with added control points on the border - that may indeed be some sort of bug - but here Rhino native, vb and python rhinoscript all find the centroid anyway without needing to simplify…