Intersection computation speed

Hi all, I am currently testing the intersection speed for the following intersection events: MeshLine, MeshRay, CurveBrep, LineCurve,CurveCurve. Currently the speed shows: MeshRay > Meshline > CurveCurve > CurveBrep (Fastest to slowest) while I was not able to use LineCurve as I required the line to be directional but the line in LineCurve takes an infinite line.

I’d expect the 2D CurveCurve intersection to be faster than the 3D counterparts, anyone has any idea why the Mesh intersections are 2-3 times faster? Is Meshray the fastest intersection computation available on Grasshopper python involving either a 3D extrusion and a line OR a curve and a line?

Depending on the situation a good strategy to is to use a fast intersector to find intersecting objects. then use the slower intersectors for details.

The new Clash component in Rhino 7 WIP is used for a lot of objects.

There is also the existing Grasshopper components: The collision many/many or collision one/many components. They output a boolean so you can cull colliding breps.

Hi Scott, thanks for the reply. I am looking at scripting methods however, interested to develop a 3D isovist script. So sadly, components won’t really help with this.

Oh, I look forward to the time comparisons.

There are a lot of isovist work around:

Yes I’ve taken a look at the link but it’s not quite what I’m interested in. What I’m looking at would require executing the 3D isovist analysis on a large array of points as such I wish to get the fastest computation method possible. Would likely take a look at working with Ghlib’s parallels.

Made a simple test script just to check if curve-curve would be the faster method compared to line-mesh intersections. Here are the results between 360 lines / 450 mesh or curves:

MeshRay (383ms) > MeshLine (520ms) > CurveCurve (900ms) > CurveBrep (4.76s)

Here is an interesting article on parallel processing in grasshopper:

Soon interesting performance studies later in the guide.