A plea to keep MeshMeshFast (or suggest alternatives)

Rhino Developer
,
1

Hello all,

I am posting in this category because that’s what I thought could fit better my request, as it regards a change in RhinoCommon. If I have misplaced this, I ask the moderators to please find the appropriate place in the forum.

I have noticed that, since Rhino7, the Rhino.Geometry.Intersect.Intersection.MeshMeshFast() method is flagged with:

Warning (CS0618): Rhino.Geometry.Intersect.Intersection.MeshMeshFast(Rhino.Geometry.Mesh, Rhino.Geometry.Mesh) is obsolete: Use the MeshMesh() method.

My use case needs to go through many iterations in which a lot of one-to-one or one-to-many tests are performed just to check if a mesh intersects with at least another mesh, no need to check overlaps of have the intersection or overlap geometries back. For this, I used, until now, to check the length of the return array from MeshMeshFast().

I have compared the execution times of the obsolete vs new method in the attached Grasshopper file. Unfortunately for me, the updated method is worryingly slower in terms of execution (~20 times slower in checking 200 intersections of 2 spheres each). I also tried with MeshClash.Search, which is considerably faster than MeshMeshIntersection, but still slower than the obsolete method.

Am I missing something or doing something wrong here? If not, would it be possible to keep MeshMeshFast in RhinoCommon? Or suggest an equally simple and fast alternative?

TestMeshMeshIntersection.gh (47.2 KB)

3

Yeah, we will see if we can get an override that disregards overlaps, which are quite expensive*. Problem is, disragarding overlaps might give bad results in overlapping areas, which are frequent in reality (we all usually test primitives on the XY plane, for example).

The old MeshMeshFast is really behaving like a blackbox, with both false positives and false negatives, and we are not really able to spend a lot of time improving several alternative versions of the same functions, which in the end do not really work. Having to choose, we strive for precision. However, there’s something that maybe we can help with. If you tell exactly what you are after in general, there might be something we can provide, and possibly outperform old behavior. In general, doing all vs all with for loops is very expensive.

Also, there is no plan to remove this function for the time being. But there’s also the problem that it has no exposed tolerance. Let me have a deeper look at it.

*) perforations do not give easy-to-use results in overlapping areas.