MeshMeshAccurate outputs additional tiny segment

[emilpoulsen]

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;
  }

MeshMeshAccurateTinySegment.gh (15.8 KB)

[emilpoulsen]

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
MeshMeshAccurateTinySegment_02.gh (19.9 KB)

[piac (Giulio Piacentino)]

Hi Emil,

@emilpoulsen

I get an extra tiny line segment when intersecting two meshes against each other using the MeshMeshAccurate method

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.

@emilpoulsen

what is causing the split? I would expect a polyline with 2 segments

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

The new code for MeshSplit

Part of a series on mesh intersection code improvements. Other Mesh Intersection Milestones… Hi all, the new Rhino 7 WIP contains a rewrite of the _MeshSplit command: fun stuff I’ve been working on for several months after the _MeshIntersect and _MeshSelfIntersect commands, which have also been slowly improving in parallel. Here a few comparison of know problematic cases for the old mesh splitter. The new one seems to be faring better for these cases. 1. Pay respect to tiny gaps [image] …

[emilpoulsen]

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!

[piac (Giulio Piacentino)]

@emilpoulsen

We had to introduce a bit extra defense to get rid of those segments in some of our tools

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.

[emilpoulsen]

Makes sense, thanks Giulio!