MeshMeshAccurate outputs additional tiny segment

Hey @piac,
Just ran into this in the latest wip (7.0.20098.14255). Seems like I get an extra tiny line segment when intersecting two meshes against each other using the MeshMeshAccurate method. I’ve attached an example file to demonstrate it. Not sure if this is expected, but certainly a bit counter-intuitive. Let me know if I can provide additional info. Thanks!

  private void RunScript(Mesh uncut, Mesh mesh, ref object A)
    double tolerance = 0.001;
    Polyline[] intersectPlSegments = Rhino.Geometry.Intersect.Intersection.MeshMeshAccurate(mesh, uncut, tolerance);
    A = intersectPlSegments;
  } (15.8 KB)

Here’s another one where it returns a polyline with 4 segments. Not sure it’s related, and not really a deal breaker, but what is causing the split? I would expect a polyline with 2 segments (19.9 KB)

Hi Emil,

thanks for the input. I created report RH-57805.

This is nonetheless partially expected. The tolerance value is too high, and that creates enormous pressure on the intersector to try join tiny gaps, thereby actually sometimes by mistake “repeating” them. This is an issue that is counteracted with several strategies, but not all of them are active in the old MeshMeshAccurate call. I’ll try to enable them also there this week. That being said, the new documentation has more information about tolerance. Please see it in the docs. This means that double tolerance = 0.001; is too big.

I’ll look into what exactly happens in this case as soon as I am around that area of code.

This is explained more in detail in this topic, part 3. The new _MeshSplit is based on top of the new _MeshIntersect intersector.

1 Like

Thanks @piac! I didn’t know the full background of the new mesh split, so that was an interesting read. I’d never thought of the complexity of intersecting non planar quads before, although the faces in the example are planar. Since quads now are treated as a couple of triangles in the context of intersections, I suppose triangulating the meshes would still produce the same results, right?

I tried running it with RhinoMath.SqrtEpsilon * 10 as you suggested, and the tiny segment is still there, but now it’s part of the polyline:

Which, again, isn’t really catastrophic. We had to introduce a bit extra defense to get rid of those segments in some of our tools, but I thought I’d let you know. Thanks again! :beers:

Yes, thank you. I think this might get an extra pass in the future, if this is thought to be a terrible problem, by using the used tolerance and then re-joining the parts if they fall within. But new features are not a high priority right now, reliability is the highest priority at present.

Makes sense, thanks Giulio!