MeshSplit MeshTrim

Run CullDegenerateMeshFaces first.
Then it’s fine.

With the bad faces, Properties says it’s an open mesh but ShowEdges doesn’t find any.
After culling, Properties says it’s closed.

Junk is junk. Maybe the Mesh commands need to report problems before they continue, like Volume does for open polysurfaces.

well said.
But why does unwelding fix the issue? That doesn’t fix the degenerate meshes, and how can I locate and fix the degenerates? And could split, trim and booleans do that under the hood with out asking the user? Would we ever need the degenerates? If not then you can safely remove them. I never saw them, I don’t even know how or where to look for them.

And thanks for being stubborn John!

Once the mesh had no degenerate faces, then welded or not didn’t seem to make any difference.

When I get a mesh related problem I do the following:
Run SelBadObjects, and isolate the problems to deal with later.
Run Check on the meshes to see if they are good. If not I fix or delete them.

Then I try to follow the user’s description.
If I can repeat the problem, I have a bug report to file.
If I can’t repeat the reported error, I backtrack to reintroduce the problems until I find it.
Report back to the user.

If I sign up for a cooking class to learn to make a souflé, then I’m given rotten eggs to use, I can’t very well blame the recipe or the chef teaching the class.

Just to make it clear:
Unwelding the mesh with out removing the degenerates made split work.

Unless other chef’s make great souflé’s with those eggs (by unrottening them), then I’d argue you can blame the chef.

Here is a pure and simple case: this is from the horse, where the split line goes through a vertex and wrongly splits the mesh.

simple mesh split bug.3dm (37.9 KB)

BTW have to sign off, it’s too late here. Cheers!

That I can get on the list for fixing.

Here is another simple fail for you.
The mesh is checked and found good.

It’s a disjoined mesh, a typical architectural minimalistic railing, and mesh trim deletes too much.

meshtrim fail 2.3dm (58.2 KB)

MeshTrim MeshSplit.3dm (296.8 KB)hello

I use Rhinoterrain to split this mesh with your curve this work nicely

Hi Claude and thanks, that’s a great result!
Just as I’d expect from a split/trim tool.

I’d expect a trim/split tool to have issues when cutting through a bad face, but I’d also expect it to just delete that bad face, because it is bad, so I’d rather have the tool remove it than fail. With a warning.

And if the bad faces are not intersected by the splitting object then I expect the tool to just split the object and keep the bad faces.

I’ve added this to the pile for the developer.

1 Like

Thanks John!
That will make our days so much better. Working with bad input is something we have to deal with and some times we just can’t afford spending time on fixing them, but still need to use them just as they are.

Thanks for understanding!

Sorry, but I think it is irresponsible to send a file to a customer with known errors in it.
If you send an STL file that does not pass Rhino’s Check command, then the chances of it actually being useful for 3D printing drops considerably.

What if I don’t want to send the file back to a customer? I would still expect to be able to split or trim it regardless of the end use.

If it’s for your own use, sure. We are collecting examples where Rhino’s mesh tools should work, like the railing example and the curve passing through a cluster of vertex points Holo sent. Those are clearly reproducible bugs.

I think this conversation is getting confusing because there are so many separate problems all mashed together.

I am really trying hard to explain that we need the ability to split bad meshes, we always have and always will.

1: Rhino IS already splitting the meshes, it just FAILS at it, miserably. With out telling the user.
2: Rhino creates bad meshes, with out telling the user. It shouldn’t if that’s such a bad thing.
3: Unwelding the mesh makes a difference, so investigate why, and how can that benefit us?
4: 3D printing is only a smal part of our need for handling meshes, so it isn’t a demand from us that they are solids or fail free all the time.

1 Like

Those are all known issues. We are aware of that.
Reporting it again and again is not an effective strategy for getting any improvement.
It just raises the frustration level.
I think it’s plenty high enough.

We continue to need specific, discrete examples of problems. Perfect examples are just like the disjoint mesh railing and the where the splitting line passed through a point with multiple mesh vertex points. Because of those excellent examples, I have high confidence those issues can be fixed. With those examples, we can pick away and the specific fixable problems and move towards a better aggregate whole. Hopefully this will include better support for bad meshes.

As my mother says, “How do you eat an elephant? One bite at a time”.

Agreed 100%

In my view, If you are going to 3d print you can spend the time cleaning up the mesh but you need to create this mesh in the first place. Currently just doing this can be very problematic, especially if you are trying to script it. There is no indication of a failure. The failures quite often occur on “good” meshes as well.

The frustration level on my side is pretty high. It seems like these issues have existed for a long time and seen little attention. If reporting them again and again gets that attention then you cant blame us for doing so. I will try to post more examples I have in the future.

I appreciate the work you are doing. Rhino is an incredibly powerful tool. I just dont want to have to resort to using something else for one seemingly small operation in the pipeline.

Meshtools in Rhino like booleans, trimming and splitting have always been broken. In my opinion they are of such poor quality, they are best avoided.
It has been so for many years now and apparently for V6 there is no change.


Meshtools in Rhino like booleans, trimming and splitting have always
been broken. In my opinion they are of such poor quality, they are best

I sometimes read harsh statements like this, which I can understand there are some things that drive me nuts too, but for me these are not so much on the mesh side of things. For Rhino being a NURBS modeller and a tool with a very wide scope I was still delighted to see the improvements in the Mesh tools from v3 to v4. I agree the advancement since then has not been progressing very fast, but still I mesh booled this STL model with +4000 intersection into a single closed mesh for stl printing back then, using the 4.0 WIP. So saying they a broken is not right imho.
Of course things could be much better and I hope they will be soon, with work being done in the sub-D area too.
but for companies doing time/project critical work on meshes often, the investment into something like magics can be a fast turnaround, such software is very expensive, for a reason.

1 Like

Hi John,
I understand the frustration.
I discovered that meshpatch and the delaunay f*cks up and creates bad meshes if it has duplicate inputs. They are not intelligent enough to sort out two points in the same spot. So I added a CullPt to my grasshopper script and rebuilt the mesh from the initial post, but splitting still fails.

Here’s the v2 of the file:
MeshTrim MeshSplit, good mesh.3dm (357.8 KB)

I don’t know if this is of any help, but the new code in MeshSplit is now able to address this case:

More info in the The new code for MeshSplit thread.



Giulio Piacentino
for Robert McNeel & Associates