Dear experts,
Is there any way in GH (other than using Brep|Brep BBX component) to obtain the intersection curve between two conical surfaces?
The Surface (pure geometry) to Brep (mesh) conversion may be expensive for some applications. This is the minimal example: ConesIntersection1.gh (17.8 KB)
Thanks!
RhinoCommon has a SurfaceSurface intersection method, you could script it. A Brep is not a mesh though, so there is no mesh conversion going on there anyway.
Hi Helvetoasur, thanks for the instant response!
I´m new to Rhino/GH, can be SurfaceSurface method called from standrd GH? Is it a plugin? Or should it be called from Python or C#?
PS: Sorry, I thought that Brep is some kind of collection of faces and vertices. I´ve now found this thread: What is a "brep"?
It doesn’t look like it’s in base GH, so you would need to use a python or C# component and script it (intersections are medium-complex to script).
A Brep is BoundaryREPresentation, it’s a way of describing not only basic surfaces but trimmed and joined ones.
The “conversion” of a single surface to a single-face brep is relatively simple, I don’t believe it will add an extreme amount of overhead.
Thanks Helvetosaur for your kind explanation. If BBX is not slow… then the nested Anemone loop I´m using in other more-complex-code may be the issue. I´m going to work on it.
Hi Seghier, I clustered the cone generation because it is something that repeats frequently (in this simple example it only repeats twice). Thanks!
In the Display menu, under canvas widgets, turn on the profiler. It will tell you how long each component takes to process…
Thanks! The profiler says that the slowest part of the loop is 7 ms (the unique shown within) but around 15 iterations take over 400 ms (Fast Anemone loop)… how is this possible?
PS: I tried both Fast and Classic Anemone loop versions.
PPS: I´ve just tried Octopus Loop and it is over twice slower, i.e. around 1000 ms.
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#?
SurfaceSurface intersection method is here:
https://developer.rhino3d.com/api/RhinoCommon/html/M_Rhino_Geometry_Intersect_Intersection_SurfaceSurface.htm
A ghpython example would be:
"""Provides a scripting component.
Inputs:
S1: First Surface (Item access, type hint Surface)
S2: First Surface (Item access, type hint Surface)
Output:
State: Boolean Value indicating intersection event
Crv: Intersection Curve"""
import Rhino
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!!!
Right click on input S1 and set the type hint to Surface. Do the same for input S2.
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)
why would you turn off parallel computing on the native BBX component? Is this a learning example/exercise?
Hi Chris,
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)
PS: Thanks for all your kind contributions!
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.
Hi Daniel, thanks for your comment!
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.
