Circle intersect points gets swapped

Replies to This Discussion

Permalink Reply by David Rutten on March 16, 2012 at 6:38pm

Rhino always returns the intersection points in order from curve start to curve end. What happens when you change the radius is that the intersection point jumps over the circle start/end point, and thus the order changes.

Basically, it's working consistently, just not in a way that you need in this case. There's two things that spring to mind you can do:

1. Rotate your circles so that the start/end point is not near the intersection points. This may be a quick fix but might not work depending on how flexible you need your logic to be.
2. A better alternative is to sort your intersection points after you find them. You can sort them based on angle or position or whatever makes the most sense within the context of your problem.

I am looking into why the CCX component returns the same parameters in the tB output, that appears to be an actual bug.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by David Rutten on March 16, 2012 at 6:40pm

Oh, it also seems that the curves are so small that the two intersection events are considered to be part of a curve overlap. Basically, if two curves don't diverge more than the document tolerance between two intersection points, they are considered to be overlapping in between. You might want to watch out for that.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by David Rutten on March 16, 2012 at 6:45pm

I am looking into why the CCX component returns the same parameters in the tB output, that appears to be an actual bug.

Found the bug. If the intersection is an overlap and goes backwards across curve B, two subsequent intersection parameters will be identical. This will be fixed when the next version goes out.

--

David Rutten

david@mcneel.com

Poprad, Slovakia