Mesh Split GH component works differently in Rhino 7

[Marco_Traverso]

Hi,

I’ve just found out that the Mesh Split Grasshopper component in Rhino 7 has a different (worse in my opinion) behaviour compared to the same compoinent in Rhino 6.

In Rhino 6, when the splitter mesh is a single mesh made of disjointed elements, the split results in two meshes (each made of disjointed pieces), so it is easy to track which pieces are “inside” the splitters.

In Rhino 7, the same operation results into a single list of individual pieces, so there is no information about which piece comes from which mesh.

I don’t know if this was done to optimize things, however with the new behaviour there is some valuable information that gets lost.

In particular, if the splitter mesh includes some “holes” the component in Rhino 6 allows to easily track the parts that correspond to these holes, which is not possible in Rhino 7.

Also, as a consequence of this, there are some GH definitions that have just stopped working, and this is going to prevent from using Rhino 7 on some projects.

Am I missing something? Would it be possible in some way to achieve the same split result as it was in Rhino 6?

Thank you!

Marco

Mesh Split Test 2.gh (16.3 KB)

[maje90 (Riccardo Majewski)]

I would say now, on Rhino 7, Mesh split works better!
It is a splitting action but on rhino 6 it returns single mesh objects with disjoint pieces, i wouldn’t expect/want that. If i want them to split, each fragment need to be a new, disjoint, mesh object.
The same idea of “Surface Split” or “Split Brep” or “Shatter curve”

You can sort the pieces by in/out inclusion

Or, if you can generalize how you want to “group” your mesh fragments, we can work on that.

[piac (Giulio Piacentino)]

Hi @Marco_Traverso

thank you for the post, it’s very interesting to read about your understanding and usage of Rhino 6’s MeshSplit. There’s no public specification about these details, so you probably checked the results like I did. I also did just that for many cases, because it’s not always easy to understand implications. Rhino 6’s algorithm was based on normals. For simple cases, it used to work fine. But for more complex ones, it very often didn’t get to the final result. For example, try putting either spheres in the first example near one another, across one another, or try to put one inside the other. Do you see the problem?

In Rhino 7, MeshSplit was entirely rewritten, and does not use normals. This means that island treatment works differently and can be tweaked. If we dialog about what you expect, we can see what applications we could get. Otherwise, there might also be some simple checks to get to the computation that you would like. Mesh inclusion in Rhino 7 SR3+ is inexpensive.

Let me enumerate how I would understand this island treatment that you like:

1. Define islands as split pieces that come from the same pair of splitter-splittee, and that do not share edges with other split pieces from that pair.
2. Islands from the same splitter get joined after the split.

I don’t mind this personally, and might not be immidiate but it’s something that is definitely possible, but I’m trying to think if it would impact users otherwise. What do you think?

[Marco_Traverso]

Hi @maje90 ,

thank you for the quick reply and for the proposed solution.

@maje90

The same idea of “Surface Split” or “Split Brep” or “Shatter curve”

Yes, maybe the new component works in a more consistent way, however the old one carried more information, and you could just use a Disjoint Mesh + Flatten component to get the entire list of pieces.

Regarding the solution, I was going to do a similar inclusion test and if there’s no other solution I’ll probably go this route, however I don’t particularly like this solution robustness-wise, as it might happen that a random point could fail the inclusion test for tolerance issues - it could be very close to the mesh edge(s).

It is still possible to overcome/limit this by populating the geometry with N points and picking the one that is furthest from the edges, or by selecting a random mesh face and extracting its center, however it was nicer and cleaner to have everything directly computed from the Mesh Split component.

[Marco_Traverso]

Hi @piac,

Thank you very much for the detailed reply and information, that is very helpful.

Probably the first time I used MeshSplit I wasn’t expecting that behaviour, but once I noticed it, it felt convenient to use that separation.

@piac

Rhino 6’s algorithm was based on normals.

Now this makes perfect sense, and this is why it felt somehow “natural”, similar to using boolean operations with open surfaces/polysurfaces, where the result is driven by the directions of the normals.

@piac

But for more complex ones, it very often didn’t get to the final result.

I know, we were using several tools that involved many mesh split operations but ultimately we had to go in a different direction because of the unreliability.

@piac

In Rhino 7, MeshSplit was entirely rewritten,

I had missed that information, this is very good news, I’ll have to take some time and test the old tools to see if they can now be used.

@piac

If we dialog about what you expect, we can see what applications we could get.

Thank you for the availability. Right now I’d say I’d just like to have that information on the normals, but since the new algorithm doesn’t use normals I’ll probably just make an inclusion test.

@piac

I don’t mind this personally, and might not be immidiate but it’s something that is definitely possible, but I’m trying to think if it would impact users otherwise. What do you think?

I think it would work, however I realize that maybe it’s not something that is widely needed, and might be confusing to most users. I think an alternative could be to add an option to the Mesh Split component (option disabled by default) to take into consideration these factors, or to have a second component, something like Mesh Split Normals, which would avoid any possible confusion.

Speaking about the inclusion test, I’m a bit concerned about using the Populate Geometry to get a point for the test, because - as far as I know- there is no way to specify a minimum distance from the geometry borders - is it correct?

I know it’s unlikely to happen, but when developing a tool that runs in automatic batches on a client’s machine you prefer to have a solution that is as robust as possible.

I can think of several workarounds, like:

• creating N points with PopulateGeometry and selecting the furthest from the borders
• extracing the end points of one among the inner edges and picking the one that is furthest from the outer edges

Probably any of them would work most of the time, do you think there is a cleaner solution?

Lastly, I think that when opening a Grasshopper file that uses the old version of MeshSplit, the user should get a warning, or at the very least a “legacy /old” label on top of the component itself.

Thanks again for your time Giulio!

Marco

[Marco_Traverso]

@piac

By the way, when setting up an example for the Split Mesh, I think I just ran into a bug (see attached file):

I know it’s not the ideal split situation with the sphere star point exactly on one of the box mesh edges, however I thought it might be worth taking a look (the same definition works correctly in Rhino 6).

Mesh Split Fail Example - Rhino 7.gh (25.8 KB)

[maje90 (Riccardo Majewski)]

@Marco_Traverso

I’m a bit concerned about using the Populate Geometry to get a point for the test, because - as far as I know- there is no way to specify a minimum distance from the geometry borders - is it correct?

I know it’s unlikely to happen, but when developing a tool that runs in automatic batches on a client’s machine you prefer to have a solution that is as robust as possible.

I’d say 0% likely, but you are right on wanting a robust solution.
But… are you working with almost tangent (each-other) meshes? If not, the splitting will already solve any of your problems of “safe distance” from the border.
Otherwise, I’ll be curious to find where and if that wouldn’t work.

@Marco_Traverso

• extracing the end points of one among the inner edges and picking the one that is furthest from the outer edges

A non-naked or “interior” edge can have an end on the border.

Kangaroo2 have “NakedVertices” component with “ClothedPts” output, any of those should be good for you.
Edit: but that component generates big lists and other useless (for the context) outputs. “Populate” with 1 point is much faster…

[piac (Giulio Piacentino)]

@Marco_Traverso

as it might happen that a random point could fail the inclusion test for tolerance issues

I doubt this is a problem, because MeshInclusion and Populate use the same check for “inside mesh”.

@Marco_Traverso

I think I just ran into a bug

Thank you, this is now tracked as RH-62439.

[Marco_Traverso]

@maje90

I’d say 0% likely, but you are right on wanting a robust solution.

I know, I’m being a bit picky here

@maje90

If not, the splitting will already solve any of your problems of “safe distance” from the border.
Otherwise, I’ll be curious to find where and if that wouldn’t work.

I was thinking about the safe distance in relation with the subsequent inclusion test (msaking sure that the point generated by the Populate Geometry is included and not on the border) but Giulio has just confirmed that is not going to be a problem.

@maje90

A non-naked or “interior” edge can have an end on the border.

I know, what I meant was among the two end points of the inner edge I’d pick the one that is furthest from the naked edges (a inner edge can’t have both end points on the naked edges by definition)

@maje90

Kangaroo2 have “NakedVertices” component with “ClothedPts” output, any of those should be good for you.

I had forgotten about it - that would work perfectly fine - thank you!

[Marco_Traverso]

@piac

I doubt this is a problem, because MeshInclusion and Populate use the same check for “inside mesh”.

OK, great to know!

@piac

Thank you, this is now tracked as RH-62439.

Perfect, glad to be helpful.

Thanks again Giulio.