Grasshopper

algorithmic modeling for Rhino

dear all,


I need to export a valid .stl file, but I can't find a way to do that...

I have two nice meshes in GH (I've checked both in Magics), but after I subtract one from the other I get a result that has a thousand mistakes that I can't fix. I have also tried exporting the meshes and performing the boolean in Magics, but that doesn't work either.

please help?

thank you in advance,
Aleksandra

Views: 512

Attachments:

Reply to This

Replies to This Discussion

Post the meshes or the script or the problem is too vague to answer.

Sure - sorry I didn't attach that.

I would be so grateful if you could help me!..

thank you in advance

Attachments:

The Cocoon mesh refinement component is bugging out and giving two nearly identical meshes that you are then formally joining into one mesh, but kissing surfaces of any kind destroys Booleans since they don't have well-defined intersection curves for the Boolean command to use to split things.

You are getting two meshes because you accidentally have *two* wires going into its LaplacianSmooth (LS) input:

Instead of totally failing the Boolean difference you are using to flatten off the blobby faces of a Cocoon ring, it leaves indeed massive little fuzzy errors. My correction fixes some other errors on the faces, but leaves the fuzzy edges:

To troubleshoot the Boolean, now that we have a simple meshes instead of a duplicated one, let's view the intersection *curves* that the Boolean will have to rely on, using Intersection>Physical>MeshMesh:

Yet they look fine, all being simple loops like needed:

You're even lucky that you get no ill defined curves as you undulating surface confronts a cutting cylinders.

To troubleshoot, I ran the Boolean in Rhino after baking:

It *should* work but doesn't:

Now I wonder if the cutting mesh is just too crude? Baking and exploding let's me look:

There's simply no mesh faces there to work with for the Boolean to leave behind since the Boolean operation can't remesh, only fix up intersections after mutual splitting, but it CAN'T since it's too bad of a mismatch. That's a hypothesis.

So let's use a custom meshing component instead of just dragging brep into a simple mesh node, under Mesh>Util>MeshBrep and Settings:


That's with Custom meshing maximum length of 0.25:

...and it FAILS exactly the same way, so my hypothesis was wrong:

Next I want to check manually in Rhino if I can just Mesh>Boolean>Boolean Split the ring with the cutting object. No, that step alone nukes lots of the mesh, tearing it off, leaving the same edges:

Well, Rhino sucks for Booleans, that's the lesson. Now that you have no more doubled mesh in the Cocoon refinement stage, move on to other software!

Let me bake and save both mesh and cutting object, and move into free Autodesk Meshmixer. Importing them separately brings up the Boolean palette, but it's going VERY slowly, doing a refining step.

I notice there is also a non-Boolean mesh split in Rhino, Mesh>Mesh Edit Tools>Mesh Split, and it WORKS:

And it retains the meshes as single formal meshes after I separate the two.

So let's do it manually, by also splitting the cutting object, and then I do have to use the Flip command to flip the cutting object fragments, but then I can use normal join and get the correct result:

Kind of a silly mesh density mismatch, so I'd go back to a custom mesh for the outside. I see now that I was indeed wrong about "remeshing" since it just adds lots of little triangles to join the densities together just fine.

So you have to create your own Booleans since Rhino is retarded. I don't know if you can do so in Grasshopper, for lack of a normal mesh split command. Nor is there a command to split a mesh with a curve, damn it. What does Grasshopper MeshMesh split do? It gives no output unless I indeed use a fine custom mesh setting, and then...gives a GOOD result, it works! Now I merely need to determine which of the two halves I want, then it will always be the same, and also split the cutter with the ring and flip the mesh then join them, and I've have a work-around for the failed Boolean:

Meanwhile, Meshmixer finally finished, rather poorly, but in a way that may help explain the Rhino failure, showing a fine feature glitch, where you can actually see that indeed, the loops that looked so good in fact had a problem of being ill-defined at one location that likely ruined the whole thing for Rhino.

oh, my!


Dear Nik,

thank you so much for the immense amount of work you've done!

Fixed script.

It's odd though since now I re-open your original and I get an OK Boolean except for the doubled mesh effect screwing with the result:

Just removing the extra wire attachment gives a good result now:

I'm not going to track down the difference, but if you Booleans stop working, indeed try the alternative of splitting and assembling "manually."

Attachments:

The manual Boolean looks like:

omg, it works beautifully!..

thank you once again!

RSS

About

Translate

Search

© 2018   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service