Oh well this is complicated and tedious.
For such a simple geometry.
I have found another method to get it done.
And as yours, it’s not error free, and requires repairs.
Repairing a fresh geometry, created in Rhino - embarrasing.
Enough ranting now.
I think the weak point here is the MeshSplit operations.
That’s why I use the term “bug”.
Tried again with the meshes in (9.0.26188.13293, 2026-07-07).
I could
It feels like nothing works as it should.
The same findings as @osuire.
That was over two years ago, and I haven’t seen anything improve since then.
I’d remove all the faulty functions to avoid disappointment.
I also never got a usable result, except in very simple, artificial test cases.
If it were a dialog…
MeshRepair lives in a panel for whatever reason, to me it makes no sense.
And it requires to re-select the mesh to repair for different ‘repair’ options.
Most of them don’t work as expected.
Can you post a sample of the new problem? Ideally in a new thread, but also here will do.
I’m analysing what can be done to make the earlier problem easier to solve, if possible. I will inform you later.
Please do not think we are not hard-working at improving mesh ops: there’s a ton of work and some of it has started to appear in Rhino BETA just a few days after you started this thread!
It is not possible to improve this problem in particular, but maybe what the command could do is a better job at explainingwhy something does not split. Look at this animated gif:
Nothing can really work because the flatter, ciseled mesh (I put it on a green layer for clarity) - on one side only - does not separeate the side in two. There is also a small spike that pierces.Therefore, that side cannot be split precisely: there is only one side. One answer could be achieved iff the answer becomes less deterministic and possibly discretized into voxels, but you can see above that the question of how to split the side is not truly precisly determined by using only the green mesh.
So, I took a run at it. The area that is Piac pints out does interrupt the the outer edge. That needed to be mended by deleting and patching the mesh. the area Piac pointed out now looks like this:
The second part that helped the new mesh intersection code in Rhino Beta was to subdivide the larger polysurface into discrete mesh faces. I using initial grid quad of 10000 for that.
Then MeshSplit against each other will result in this:
I was thinking about this some more, and here is a little trick that makes these cases much less mysterious: before trimming or splitting, run plain _MeshIntersect on the two meshes first, and look at the curves that come back.
For a split to be possible, those curves must completely separate one side from the other: either a closed loop, or a path that runs all the way from border to border. If a curve just stops somewhere in the middle of the mesh, that is the spot where the split becomes in part undecidable, and every command downstream (MeshSplit, MeshTrim, MeshBoolean…) will give up in some way, or try to carry on with some hindrance. In your file, that happens on one side: the intersection with the “green mesh” (colored above) stops instead of closing the tour, plus there is a small spike piercing through nearby.
Once you can see the open end, fixing it is usually the quick part:
patch, delete and recreate few faces around the open stop (_3dFace, _FillMeshHole and the gumball are your friends), or
extend the cutter so it passes fully through the other mesh, or
like Scott did, mesh the polysurface much denser first (initial grid quads at 10000) — the new intersection code in the beta will narrow down the problem to a smaller spot.
You also had a point about the commands staying silent. I logged this so the commands themselves will get better at explaining why and where a split cannot happen: RH-97369.
The very first thing is the bad displacement mesh.
Rhino should not produce bad meshes, agree?
Second is MeshRepair.
If the mesh is bad, at least MeshRepair should, if it can’t repair, point me directly to the error zone.
Nothing like this happens.
That’s a good hint, practically the same as with NURBS problems.
That’s good and will help.
@piac
MeshRepair lives in a panel.
A panel? Why?
From the Mesh - Repair menu you can’t reach it.
Shouldn’t MeshRepair be accessible from a menu that offers Repair tools?
Confusing.
Oh man, please ping me with the geometry next time. We will find a way together to make it work, if it’s possible in general.
Yes, I’ve seen your video and it’s reasonable. I reported RH-97418. In general, “Displacement” is very free in its parameters, so it’s possible that it will create some invalid mesh with some combinations of settings + geometry. I think, at least, it should warn about it.
Thanks!
We should add some other way to access repairing functionality. Rhino BETA starts to have some amazing repairing mesh functionality, but not all is easily discoverable. I reported RH-97369.
