Hi, sorry, around 400 ms for around 20 iterations means about 20 ms per iteration, so it seems that it is just what it takes…
I computed just one single intersection curve between two cones outside any loop, and it takes the same outside and inside the loop. This means that it is just a matter of GH speed. I´ve haven´t ever figured out that this task would run that slow in a modern i7 (4.0 GHz) computer.
Is there any faster approach than BBX to obtain the intersection curve between two cones? (from standard GH)
If not, would somebody show me how using SurfaceSurface method from GH using Python or C#?
"""Provides a scripting component.
S1: First Surface (Item access, type hint Surface)
S2: First Surface (Item access, type hint Surface)
State: Boolean Value indicating intersection event
Crv: Intersection Curve"""
tol = Rhino.RhinoDoc.ActiveDoc.ModelAbsoluteTolerance
State, Crv, Pts = Rhino.Geometry.Intersect.Intersection.SurfaceSurface(S1, S2, tol)
I have no idea if it would be noticably faster than the native BBX component.
Hi Chris, thanks a lot for your contribution. I haven´t ever worked with a Python plugin in GH. I copied your code into a Python GH component but I couldn´t make it work. This is what I tried: ConesIntersection2.gh (21.7 KB)
Perhaps you can share with me your test file. Thanks!!!
Hi, it seems that the SurfaceSurface method (SS) is around 30 % faster than BBX, but only if “Parallel computing” is disabled in this later (by right clicking on it). In this is the test I computed 100 random intersections between two cones in 366 ms with BBX (serial) and 254 ms with SS: ConesIntersection3.gh (25.9 KB)
I toggled Parallel computing option because sometimes it takes more time to initialise the parallel stuff (internally compilers guts) than performing the task in serial. I´ve just made some tests. The Parallel speed up of BBX inside an Anemone loop does not speed up at all wrt serial (parallel computing disabled), instead of the 2-3 fold expected from the raw tests. In fact, some very marginal slow down is observed. Unfortunately, the Python interface with SS method is only slightly faster 10-20 % in my particular script. That´s not a huge improvement… Thanks anyways!!
I´ve found one minor issue with SS method. It returns two curves sometimes, at least with cylinders. I had to join them before employing the Join component. The boundary between both curves is the Brep line border, as you can see here:
To whom it may concern, whenever… I´ve just realised that two cones intersection can be simplified to the intersection between one cone and one plane (Brep|Plane component, Sec).
Accordingly, the relative times to compute 100 intersections cone-plane become 45, 93, and 224 ms for Sec, BBX, and Python based approaches (Parallel computing enabled). If I enable Parallel computing, times become 183, 339, and 234 ms, respectively. Thus, the cone-plane intersection method is always the fastest.
This is the test file, I didn´t do the stuff to properly place the plane between both cones, but it should not take too long: ConesIntersection5.gh (35.9 KB)
If your cones all have the same angle, vertical axes, and their tips lie on the same horizontal plane, then the intersection is always going to be a hyperbola in the bisecting plane of the 2 tip points. You could even construct this hyperbola yourself explicitly, skipping using the standard surface intersection methods altogether, and it would probably be way faster.
You´re right, but I don´t know how to generate an hyperbola from vertex and the required constants to define the curvature. I discarded this option since it seemed too complicated to find how, but if you know how I would try.