The new code for MeshSplit

[piac (Giulio Piacentino)]

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

The new code uses a more advanced intersection algorithm in order to minimize the places where tiny gaps result in intersection conflicts. The precision of the triangle-line intersection code is about double in respect to the old code.

2. Handle overlaps with care

The old splitter simply refused to split the plane with the extruded shape above. This is because large overlaps were often misinterpreted. The new splitter tackles this with code that deals specifically with overlaps, not treating overlaps as intersections per se, making sure that the ones that are within tolerance get handled as overlaps and are computed separately. An overlap that is also an intersection should result in an overlap.

3. Same level for all (quads)

Earlier on, all quads were logically treated as planar. But they may well not be. In fact, almost each quad that is not on one of the three fundamental planes is not planar. This means that, in each place that had a non-planar quad, some magic had to happen to make gaps properly close. You can see this in the second picture above. The new code always treats quads as a couple of triangles, where the shorter diagonal creates the two planes.

Although being much more robust, this last decision means a few more intersection points for quad-quads and quad-triangles intersections. This difference might not be always visible, but is present.

If you feel like trying the new code in the WIP, and see anything (good or bad), please let me know.
Also, note that MeshTrim, MeshSplitWithCurve, and all other commands still use the old splitter. The new one will be adjusted to the needs of the other commands as next steps.

Thanks,

Giulio

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

PS: As usual, here the cases that I am discussing above.
mesh-split-cases.3dm (110.5 KB)

[wattzie]

Is this code implemented in Rhino 7? Is there an equivalent that can be used to replace _SplitMeshWithCurve that could help for this example:

Rhino 7; SplitMeshWithCurve issue

Hello, I’m in the process of converting Rhino 5 scripts into Rhino 7 scripts, and I got weird results using SplitMeshWithCurve function. Here is the mesh I’m tring to split, with the splitting curve: [image] Here is the result: [image] The big mesh remains, and some triangles make another mesh (shown in yellow) Here is the testing code: mesh = rs.ObjectsByLayer(“Input_Mesh”)[0] curve = rs.ObjectsByLayer(“Input_Curve”)[0] cmd="-_SplitMeshWithCurve " + "_Selid " + str(rs.CopyObject(me…

[piac (Giulio Piacentino)]

@wattzie I replied there! Thanks for the link, you can also just @-mention me there.

[Holo]

Can I wish for a Mesh-Cut command?

I want to split into the mesh, with out splitting parts apart.
Basically cutting halfway in or just internally.

Kind of like this:

Would that be possible?

[piac (Giulio Piacentino)]

@Holo if I understand correctly, this is now possible. There’s an option in MeshSplit, “DiscardUnsplitMeshes”. Try turning it to “No” and see if it helps. It basically allows to incorporate the splitter mesh into the to-be-split one, even if they don’t form distinct areas.

If this is not enough, we can probably start a new topic and try to address this in more detail!

Thank you

Giulio

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

[Holo]

OK, thanks. I would need that in programming. (Python or Common) is that available yet?

[laurent_delrieu]

Hello Giulio
I tested the command and Grasshopper, I still have some problems.
Rhino 8 SR0 2022-12-6 (Rhino WIP, 8.0.22340.12305, Git hash:master @ d4a00cc453abcfe9fc7a8e109856bf957cdda0d3)
License type: Commerciale, build 2022-12-06
License details: Cloud Zoo
Expires on: 2023-01-20

You will find the file with data here

Bug in Mesh Split

As asked by @wim here is a file with A mesh, some meshes as cutter and differences with my tool and Rhinoceros. As many cutters are on the borders there are lots of little meshes. But cutter in R8 seems to still have some difficulties. 3 cuts vs 80 !!! [image] bug mesh split V2.gh (1.7 MB) Rhino 8 SR0 2022-11-15 (Rhino WIP, 8.0.22319.12305, Git hash:master @ a78287b93af89333d2c1832fd6a67d321a15ee29) License type: Commerciale, build 2022-11-15 License details: Cloud Zoo Expires on: 2022…

[siemen]

So far the MeshTim command seems to be working quite well in terms of splitting the mesh. I did notice it messes up the color of the mesh face. (To be honest I don’t often work with meshes so I also don’t know of this was the case before as well)
Before MeshSplit:

After MeshSplit:

Edit: Maybe this is not related to MeshSplit but actually to the Join command?

[Holo]

Hi @piac I see that this works in Rhino Common too.
Neither mesh get’s naked edges (or visible edges) along the new cut though, so an unweld needs to be done.

And I see a bug: When splitting quads Rhino ignores the quads and uses the triangular mesh instead. That is a bug IMO since it ads a lot of extra points to the split.

[scottd (Scott Davidson)]

There is a thread on the texture coordinate progress here: Great new mesh booleans but what about texture - #9 by martinsiegrist

Showing the exact commands, results and steps helps understand how the TCs are getting messed up.

[piac (Giulio Piacentino)]

@Holo

When splitting quads Rhino ignores the quads and uses the triangular mesh instead. That is a bug IMO since it ads a lot of extra points to the split.

This is by design. Unless on one of the planar axes or by some miraculous chance, all quads are non-planar (also because of rounding). This means that using quads as planes will never really give a single answer. And this was one of the identified culprits in the old code. So, we decided to always use the mesh as though it were triangulated. This is the only way to ensure meaningful results. We could have a pass, later, that removes these points, or a command that does that altogether, by some tolerance. But just know this was carefully though about!

[Holo]

Thanks, stability rules, so if that is what you needed to do, then I’m voting for it.
But I would really like to see a much cleaner result, so I’ll see if I can find away around it.

Oh, can you please check if Rhino’s triangulation of quads could be the same as the OpenGL pipeline’s?
They often don’t match, causing curves projected onto meshes to appear to not be “on” the mesh in those areas.

[piac (Giulio Piacentino)]

@Holo

But I would really like to see a much cleaner result,

With those quads, we are living a deception. Rhino uses triangles to draw them, and they can be extremely nonplanar. All the trick is about, is to avoid drawing the lines that are used behind the scenes. There’s an additional weird fact. Quads and triangles can create ngons, and they can be even more nonplanar. All polygons above 3 can be nonplanar in Euclidean geometry. I understand that hiding the point of their intersection might make the king seem dressed, but he is naked!

To leave the analogy a little behind, where are you seeking improvement here? The fact that some quads might be precisely planar but a new point appears? Or the fact that you need to count intersecting faces for some scripts, and there are more pieces? Or something else?

Believe me, I have had to keep these things in mind, for a loong time. I also wish sometimes that things were very simple.

@Holo

can you please check if Rhino’s triangulation of quads could be the same as the OpenGL pipeline’s?

Yes. That is a long-standing bug in my opinion, too, but it’s also an optimization. Adding it to the bug tracker. Btw, the mesh intersetion code uses the same decision system as TriangulateMesh. Not the one of the OpenGL pipeline.

[Holo]

Yes, building meshes from vertice lists and facelists are tough, I just made a road builder that “sweeps” my custom mesh along a curve. (Only way I could get descent quad meshes just the way I wanted them) And keeping my head around how to pick the correct points form the list for the faces as I added both was a challenge

And this is where I need to split the underlying terrain so I can get more vertices, but not more than I need, so I can adjust it to the new road.

It would be great if the quad mesh face could be considered a “frame” that doesn’t care about where it’s underlying triangles are, and thus splitting it only where needed, but I can imagine areas where this won’t end up with the same points on both parts. (splitting a surface with another surface that already has been split with the first surface has always been an issue with Rhino. So I guess the same can apply to meshes) I’ll do some tests and see where I end up. If I get some good results I’ll keep you posted. Thanks for your thorough replies, they are excellent food for thought!

[Holo]

To keep this on topic:

I get good results with mesh splitting of terrain now, I custom extrude the curves I want (straight up for road shoulders and at 45 degrees out both up and down) and then split with all of those six extrusions and then adjust the vertices to the road base height and for the cut and fill. This results in one joined mesh to avoid boolean errors. And if it causes errors it just continues anyway.

Just wanted you to know.

One question though, is the new code added to V7? Or is it just for V8? If so then I guess this is off topic after all

[piac (Giulio Piacentino)]

@Holo

One question though, is the new code added to V7? Or is it just for V8?

Most of the new optimizations are only in WIP, but MeshSplit has already been rewritten starting from V7.

@piac

That is a long-standing bug in my opinion, too, but it’s also an optimization. Adding it to the bug tracker.

@Holo On our bugtracker now, different quads - RH-72067