I notice this is not in RhinoCommon under the Intersect:Intersection class… There is line/circle and plane/circle, but no circle/circle. It might be useful (I could have used this recently at least), so perhaps it could be added at some point?
Thx, --Mitch
Intersection.CurveCurve(c1.ToNurbsCurve(), c2.ToNurbsCurve(), ...)
should do the trick.
Thinking about the consequences of intersecting two general circles, which may or may not be on the same plane, it seems to me that the complexity is more or less on par with the existing curve-curve intersection methodology.
A quick test to see if they intersect at all is to do a BoundingBox intersection test.
Hi Menno,
Sure there are workarounds… The same could be said for a number of the “mathematical” solutions in Intersect such as Line/Circle, Plane/Circle, etc… The point was that as circle objects are mathematical constructs, to have a mathematical solution without having to convert to NURBS - in the same way that the other cases mentioned above do.
As far as complexity goes, there can be 0, 1 or 2 intersections possible just as with line/circle. If 2 intersections, it should output the circular parameters on both circle objects…
No big deal here, I was just suggesting it for sake of completeness.
Cheers, --Mitch
Should this specifically work for any two circles or only circles in the same plane?
Hey David,
I would expect it to work like the other two methods I mentioned, Line/Circle and Plane/Circle… Both of those can - as far as I know - deal with any two objects. If they don’t intersect, it returns None, if they do it returns either one point (parameters) or two… Is there that much difference in the methodology of say a line/circle intersection and a circle/circle intersection?
Thanks, --Mitch
Well a line can be projected onto the circle plane while remaining a line, whereas a circle cannot without becoming an ellipse if the initial planes have different z-axis directions. In either the Line|Circle and the Circle|Circle case, some sort of tolerance has to be used to determine whether an approach qualifies as an intersection, unless the line is projected onto the circle plane. The existing method does not have a tolerance argument though.
I’m totally in favour of adding more methods like this, but there seems a fundamental disconnect between having ‘exact’ analytic intersector methods that require a tolerance to work…
I was more thinking along the line of a circle being defined as
p(t)=o+xsin(t)+ycos(t)
where p, o, x and y are 3-tuples (the origin, X- and Y-axis of the circle plane, respectively)
Then you want to compute the equality of two circles
p(t) = o1+x1*sin(t)+y1*cos(t)
q(u) = o2+x2*sin(u)+y2*cos(u)
p(t) = q(u)
solve for t and u
The Rhino SDK does not have a circle-circle intersector, which is why you don’t find on in RhinoCommon.
There are plenty of algorithms floating round out there that explain how to calculate the intersections. Here is one such algorithm implemented in C#.
https://github.com/dalefugier/SampleCsCommands/blob/master/SampleCsIntersectCircles.cs
In the example, CircleCircleIntersection calculates the intersects two circles that lie on the world x-y plane. If you’ve deemed your circles to be coplanar, just transform them to the world-xy plane, run the calculation, and then transform the results back to the original plane.
Well, this was just a suggestion that such a method could be added. Take it for what it’s worth…
–Mitch