Now I’m in really deep trouble. MeshSplit doesn’t split properly in Rhino 5 GH, and not in WIP (2017 Sept-19) either.
My meshes are “good” according to MeshRepair. See pictures below from trying to split using WIP - which still has the same ugly old bug as Rhino 5.
I have tried different approaches, splitting with Mesh/Mesh using BoundingBox/Breps->Mesh (no go), Planes (no go), NurbsSurfaces (no go). All of it. No go.
This is serious. A showstopper. And it is very disappointing to find out that this bug has been reported long ago.
Fig 1. The black parts are missing after the split operation:
Yes, that’s why it’s so disappointing that it hasn’t been fixed. I’m into a very challenging project, and with this I will have to reevaluate if Rhino can be used as the application platform.
Yes, absolutely. I have tried multiple variants but everything fails. But I’ll post that which is pictured above.
This definition uses surfaces to split, but I have tried planes and boxes, but same problem. MeshSplit Test 000.gh (3.4 MB)
Hi Rolf, I had a look at your file and unfortunately Rhino is really bad at splitting meshes. It might be true that this is all due to bad meshes, but it doesn’t change the fact that users need all kinds of meshes split.
The simplest examples I have found is shown here:
And if you take a look at this file part of your file and try to run a meshintersection on the two parts you will see that it messes up. This is typical for how rhino handles mesh intersections when it fails. meshsplit meshintersect bug.3dm (188.5 KB)
Hi @Holo, yes these are not very good looking meshes (although useful for my purposes after making them more isotropic) and I also do some heavy cleaning up on them. But the “better” meshes doesn’t give any better results when trying to split them.
Problem is of course that splitting is one of the most basic operations, and therefore so often needed. It’s basic.
Although I’m not the smartest programmer ever, I actually do advanced things with the meshes, things which I do not expect Rhino to handle for me, simply because it’s so “special”. But splitting a mesh isn’t special. It’s special only if end users must develop their own algorithms to fix (also) that bit. And in my case, if I can’t split a mesh, then I can’t really do much with Rhino in this field (a research and a pre-operation planning tool).
It looked so promising because Rhino has an interesting mix of tools and functionality. But this “chain” fails again and again on the most basic things. The weak links on a chain should not be the chain links.
It seems I have come to a dead end with this.
I was afraid of this. Because the people who wait for this tool for a special kind of shoulder surgery (and after that, two other tools for knee and hip-surgery) keep talking about Materialise. And I begin to understand why. But I have resisted, for several reasons. I also found it interesting that end customers can have a Rhino license for only a monthly fee of M.
But if the surgerons are going to cut bones according to plans produced by a Rhino based tool, then Rhino needs to be able to do basic things like cutting a mesh. I have tried so many things, but nada.
This was really bad news to me. Really bad. It should have been fixed already in Rhino5. It still should be fixed, starting with Rhino5.
Well, yes, if you look through the various forum posts here, you will see that mesh operations based on intersections (splitting, trimming, etc. ) fail fairly frequently. While the level of user interaction and customization of the program are second to none, the fact is that in Rhino meshes are still simply second-class citizens. And while that situation may improve somewhat in the future (hopefully), it will certainly not happen for V5 - nobody’s changing anything there. And I expect that the type of core development necessary to improve the mesh intersector is far beyond the scope of what will end up in V6 - which is also pretty much a done deal at this point.
Keep in mind too that Materialize (Magics) has been in the mesh fixing business for like 20 years… That’s a huge amount of geometric core development focused almost entirely on mesh processing, fixing and editing (you can’t even model with it !) - that’s why they still get the big money from people who need that level of use and reliability.
Yes Mitch, but I do quite some mesh fixing too, in part with my own algorithms and other things using external tools for which I developed some components :
(although MeshMixer doesn’t really work for now due to some issues with x64/x32 dll-hell).
But as said, I don’t expect Rhino to specialize in mesh fixing. But if I can’t even cut a mesh, then I can’t do even the most basic things geometry with it.
Since we get mesh vertices from meshes, and FEA needs isotropic meshfaces, basic mesh handling (again, not fixing) is essential. Not mesh fixing, but meshing of breps, traversing and cutting meshes. There’s no way you can get away from that.
“Basics” is only defined in context, and I don’t think I am exaggerating when I claim that cutting a mesh belongs to basics in this context.
If anyone out there is capable of making a workaround, preferably with a GrassHopper component, I’d be listening very carfully. Tomorrow the concept was planned to be presented for a group of professors and surgeons in a “hot spot” in the field in Europe, and I hate the prostect of having to postone the presentation.
I’m trying to seep in that Rhino was a false lead, because of trivias like this.
I know, yes I really do believe that McNeel developers do their best to make an awesome product. And Rhino is an awesome product, in so many ways. But if it’s not as useful as all the bells and wistles promises, due to such trivia as this, then you guys really need to reconsider your priorities.
It came to mind since I just read about Mr Trump’s inspection of the Gerald R. Ford-class carrier and it’s new fancy electromagnetic catapult. Incredibly expensive solution which officers, the end users, says doesn’t actually work.
So Mr Trump asked some project leaders what solution they’re eventually aiming for, quote
“[Mr Trump] said what system are you going to be–“Sir, we’re staying with digital.” [Mr Trump] said no you’re not. You going to goddamned steam, the digital costs hundreds of millions of dollars more money and it’s no good.”
You going steam, guys.
// Rolf
Edit:
Noticed your post just now. I have tried with isotropic versions of my meshes (fixed with my Instant Meshes component, pictured above) with no luck.
With only very few cuts, like one or two, sometimes even three, the posted meshes may be cut as expected, but add another one, and parts are missing.
I have tried to determine if there’s a certain “pattern” in how the cutted parts drop out, but I haven’t seen any yet. (you AI guys out there would quickly find a pattern though, which may prove to be helpful in tracking down the actual cause of this bug).
I want to add that yes, I’m almost panicking now, but I don’t want to sound arrogant. This is a nightmare for me.
Having said that, I may well be an idiot for still trying, but I’m still prepared to consider workarounds. People out there might have the skills it takes to cut meshes, no? I’m still looking for solutions.
Any known well proven mesh manipulation libraries out there that could be wrapped? Testcode? Anything reasonable that has a deterministic outcome, which can be shipped with an end product.
Still requires that you get the correct intersection, which is what Rhino is failing to do… If the intersector worked reliably, then the rest would follow. But I think if it was a trivial fix, it would have been done already.
Trivial fix and trivial functionality (from a user’s perspective) isn’t the same thing. One is the product, the other is isn’t.
Don’t get me wrong. Bugs in non-essential and non-trivial functionality in a product is excusable. With a background in industrial production and QA, this is the kind of thing that would have made me stop all production (all production) until fixed.
Stopping production is both a “language” and a means to give hard striving high ambition people to do a good job, loving doing it.
Well, that’s up to McNeel. As I said before relative to a V6 target - seeing as we’re already 5 years into development, that seems rather unlikely IMO. --Mitch
That very same situation isn’t going to help the magnetic catapult making it into Gerald R. Ford carrier one bit.
When I say “go steam” then of course I’m not addressing you. I’m not encouraging you to reconsider, or actually revert priorities according to sanity check.
“Today, USS Gerald R. Ford made history with the successful landing and launching of aircraft from VX-23 using the AAG and EMALS,” said Adm. Phil Davidson, commander, U.S. Fleet Forces.
Hi Rolf, I started working on a simple split-mesh-by-plane script now, and it looks quite promising.
It will use a location and world X, Y and Z as plane input only.
How fast must the splitter be?
Yes, I do have a component for running MeshLb from GrassHopper, but I couldn’t find any split command in there.
Wow, that sounds interesting! I don’t think the speed is very critical in this case, at least not in most cases. If you just come up with something that actually works.
Disregard (almost) mesh quality, just chop things off, preferably using a surface since Planes would cut through where I would like to stop, for example in knee-corrections, where the knee is cut only “almost through”, and then tilted so as to make room for a wedge in the cut. A Plane would cut right through.
I’m very very interested!
(Edit: But a Plane cut is useful too, like in my pictured example above!)
Yeah, I thought about that too, intersect mesh edges (line segments) with the plane, that can get a list of intersection points reliably (not necessarily fast though). However connecting the dots in the right order to form a closed intersection polyline is not all that easy if the mesh is irregular… Plus you still have to split the mesh with the polyline one way or the other…
Otherwise, converting each mesh face into a planar srf and splitting those with the plane should work and be reliable, then re-creating the mesh from the resulting surface collection. But that will be pretty slow with large meshes methinks…
Hi Rolf, I thought a plane was what you needed, and that I am sure I can manage.
Here I have located all the faces that are intersected and made separate meshes of the parts.
It took 2.5 seconds, so not very fast yet. Edit: This is only the beginning, to make sure I can do the rest of the job. So now that they are located I can start modifying the vertices of those orange faces.
