The improved MeshIntersect & the new MeshSelfIntersect

Serengeti (Rhino WIP) Mesh WIP
, , , ,
1

Part of a series on mesh intersection code improvements. Other Mesh Intersection Milestones…

Hi all

this week’s Rhino 7 WIP contains:

  • a completely rewritten _MeshIntersect command
  • a new _MeshSelfIntersect command

This is fully new code, so it is on by default, but you can choose to switch back to the old code.

The new intersector is designed to be more tolerant of overlapping mesh areas, as well as more tolerant of adjacent edges and superimposed vertices.

overlap-difference
overlap-difference.png1166×965 324 KB

The new code takes a different approach for large groups of intersections, and because of this, it can greatly enhance computation times for many objects. In this example, 3456 meshes with over 500’000 vertices are intersected. The new code takes a little less than 3 minutes to complete on my system. The old code, even if only fed just half the amount of meshes, did not finish in 10 minutes and I had to manually terminate the program. In addition, next week’s release will even improve this case, bringing it down to about 1 minute.

massive
massive.jpg996×653 590 KB

massive.zip (2.1 MB)

All this good news, but there’s a caveat: this new functionality is not entirely finished, and we decided to release it now because there are at least a few cases where we see these improved results.

Please let us know if you discover new bugs. We are aware of a few ourselves. In some cases, the code is even able to tell the the intersection it created was wrong. In these cases, it will print this:

An intersection computed a wrong result. The causing triangles are:
_3dFace 112.20292663574219,-8.9776668548583984,-2.1148440837860107 112.0255126953125,-9.1104488372802734,-2.1148440837860107 112.056396484375,-9.1504192352294922,-2.110210657119751 _Enter _3dFace 112.14628150413222,-9.0820278911035253,-0.72244736380784214 112.05639961329504,-9.1503509181935208,-4.6081842704980511 111.96749762268365,-9.2201260610692586,-0.72244736380784214 _Enter
Found 0 intersections using tolerance of 0.001000. Largest intersection computation gap was 0.000512.

In this case, you can isolate and send only the few triangles that caused corruption of the entire intersection (the second line is a macro that can be executed by you). This way, it will be easier for you to let us know and debug new cases even without your model. In general, the code progresses without interdependencies, so even if you encounter a small area that does not intersect correctly and that is not reported, it will be OK if you simply _ExtractMeshFaces and send us the result.

Thanks,

Giulio

–
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

8 Likes
2

Super cool Giulio! Is this functionality extended to trimming meshes with curves as well? --Mitch

3

Thanks!

This functionalty is only affecting the mentioned commands. You will be told once this will be extended, which is planned but will take a while.

4

Ah, OK - so things like MeshBooleanUnion/Difference/Split do not yet use the new intersector?

5

Not for now… Right now the focus is on _MeshIntersect and _MeshSelfIntersect.

7

OK, thanks…

1 Like
8

@piac Good news! Just out of curiosity: does the new code make use of multiple CPU cores or perhaps even the GPU for parallel processing?

9

We thought about this; there’s only some minor benefit that can be added when doing this multi-threaded. Please note that the old code was multithreaded but it’s way way slower for large groups of meshes than the new one (100 : 1 ratio). We will investigate all means to make this very robust first, then possibly add multi-threading for parts where it makes sense. I wouldn’t expect much benefit from this.

10

Fingers crossed for more mesh tools to get serious and working properly!
( trim / split / Booleans / offsetmesh ). Hope this is a first (major!) step in that direction.

–jarek

3 Likes