I’m experimenting with the Wasp definition outlined in this tutorial. by @ar0551
The question in this post does not require you to have Wasp. It is a basic mesh and grasshopper question. (Wasp is fun though! Get it!)
The baked result I got, after running a ghpython compontent that does _addngonstomesh, look like this:
Each pentagonal prism is a single mesh object.
What I’m trying to do is combine all of the prisms into a single volume by exploding, deleting the adjoining duplicate faces, and re-joining.
MeshBooleanUnion in Rhino doesn’t work, because I want to maintain the Ngon exterior faces shown. The end goal is to convert to SubD after rejoining. Ideally it can all be done in grasshopper.
How do I find the duplicate faces and cull the duplicate faces and the originals?
Here is the geometry in a teeny grasshopper file: Wasp One Volume Test.gh (197.3 KB)
Here is the entire definition, originally from the tutorial with a few components added, including the ghpython component linked to above: Andrea Rossi Wasp Tutorial Tweaked.gh (222.0 KB)
Update: I just discovered that the Explode Mesh component undoes my conversion of the faces to Ngons. Suggestions for a better option?
The concept is simple: pick the center of each face and with “Cull duplicates” set on “Cull all” you can then remove the duplicate faces by using the indexes of culled points.
Problem: your meshes did not have aligned vertexes! Probably in some step of your workflow there was some deformation or such…
Also, some face had duplicated vertexes… !!
I had to re-aligh the vertexes, but if you manage to have clean meshes that step shouldn’t be needed.
Wasp One Volume Test_re.gh (203.5 KB)
Thanks. I think there’s a component in the Ngon plugin that can explode my mesh faces without reducing them back to their original triangles. If the prisms are all made up of two pentagon faces and five quads, maybe no need to look for duplicate vertices or non-aligned vertices?
I’ve never worked with Ngons, and I wouldn’t if I don’t have a reason to.
Ngon to “normal” mesh maybe is unpredictable? Just avoid it and use normal meshes.
For your case, if you use simple extrusions and then do the meshing with “Simple planes” = True, it will make meshes as simple as possible. With no problems of alignments or else.
Also, working with meshes make things speed up generally, both in managing and visualizing.
If it is a simple shape like in your case, you might prefer to switch to mesh asap…
… even if you lately need brep again, you can re-build them from the meshes in a clean way.
The reason I’m using ngon mesh faces is that SubD objects generally work best when they’re mostly quads, with occasional triangles and pentagons here and there in special circumstances (more rarely, a 6 or more edged face can be handy).
My ultimate output will be NURBS polysurfaces for CNC routing. To get there and get good curvature, my workflow will be Mesh to SubD to NURBs.
I’m now using the Ngons plugin’s “explode mesh” component in my definition after the ghpython “addngonstomesh” component to explode while preserving Ngons. After I get the culling working, I’ll upload a definition that ends with a single volume mesh for Rhino 6 and a definition that ends in the Mesh to SubD component in Rhino 7 WIP.
Below is what the result of a manual workaround looks like. Understand I’m working with one very simple module at first so I can do proof of concept. Later, I’ll try more complicated sets of parts, which is what Wasp plug in is made to do.
That make it all much more sense… i was wrong then!
Anyway, if you manage them to be “clean” with coincident vertexes, the trick with duplicate points to remove duplicate faces is the same.
Cool stuff, I am curious to see where you will take this!
The problem you are facing starts from the fact that you use a BRep as a input for the Wasp Part. What the component does when supplied with a BRep, is to do a standard mesh conversion, which use only triangles (no idea why, but that is what Gh does).
In your case, it is key that the mesh you provide has some features (particularly, quad faces on the sides). The best solution is to do the conversion yourself, ensuring that it creates the right mesh, and then use that mesh as input for the Wasp part component.
Once you do that, you will be able to remove duplicated faces how @maje90 suggested.
I attached a small definition showing how to do it.
Andrea Rossi Wasp Tutorial Tweaked_FIX.gh (225.6 KB)
This is closer, but not quite what I was trying to do. I’m trying to get output that’s only pentagonal faces and quad faces, and this merges some of the pentagonal faces into irregular octagons, and leaves other faces split into triangles.
It does look like you may have shown me a bunch of components and processes that I can re-arrange to get where I want, though. I will attempt on my own again, and ask for help if I get stuck.
Uhm, you might try to do the ngon conversion directly on the base mesh of the part, and use that as the Wasp part geometry.
I have not tried it, and not sure what would happen, but might work. Unfortunately I do not have my laptop now. Let me know if you get it to work, in case I can check it tomorrow for you.
I’m working my way through doing the Ngon conversion on the individual modules, then exploding them, then culling duplicates, then joining what’s left.
I’m very new at meshes in Grasshopper. I can’t find a way to explode the modules after Ngon conversion that doesn’t undo Ngon conversion and give me a bunch of triangles. Currently attempting to use
face boundaries to
boundary surfaces, do the sort and cull with surfaces, then turn them all back into ngon mesh faces, then join and weld.
Seems like there must be a way to avoid bringing surfaces into the mess, but I can’t find it.
Hopefully when I get it figured out it can work with any Wasp aggregation that’s made of planar polysurfaces.
Also: I tried Wasp in the Rhino 7 WIP but got glitches. Is there any extra step I might need to do to get it to work? (Totally understandable if it doesn’t work. Just eager to use the subD conversion component at the end of my definition.
Here you can do the conversion through only the face boundaries, without bringing surfaces in the picture: Andrea Rossi Wasp Tutorial Tweaked_FIX2.gh (237.5 KB)
You need to have Weaverbird installed though.
About Rhino7, I never actually tested it, and I do not really know what the problem could be. What is the problem you are encountering?
1. About running Wasp in the WIP:
The error I get is this:
2. About the definition:
So, culling worked perfectly, but joining the results into one volume still doesn’t allow me to keep the ngon faces.
Maybe I’m doing something wrong? I haven’t done much work with meshes at all. But it seems like a bunch of important mesh components in grasshopper all really really want to re-triangulate my ngons.
mesh join does it. The
weaverbird's join and weld does it.
simple mesh reacts to penagonal ngons input by ignoring a vertex entirely and leaving a hole.
So, I tried using conversion to surfaces. It’s sluggish as hell, but it works on any volume, as long as there are no manifold edges. Here’s my definition: Andrea Rossi Wasp Tutorial Pentoroid.gh (249.3 KB)
And here are some results:
These are all closed SubD objects that can convert easily to closed NURBS polysurfaces. The only glitch I encountered at any point was that nonmanifold edges get weird and leave holes. Otherwise it’s been perfect every time. SubD’s ability to blend between parts, and have the nature of that blend be affected by the nature of the junction and adjacent junctions is fun.
the Rhino 7 error should be fixed in the next Rhino WIP (see here).
About the ngons, I guess the problems comes from the fact that in Rhino, NGons are not actual mesh faces, but groupings of these mesh faces. So, your mesh has still the same amount of faces (either quads or triangles), but some of them are merged at display to show faces with more than 4 edges. Problem is that most Gh components working with meshes operate at the face level, and by changing the faces structure, they delete the NGons structure attached to them.
I believe the best way to address this is to avoid using Gh components and do everything via scripting. I will see if I have a bit of time and try to see if I can work something out. I let you know in case
And besides all this, super cool images!!! Are you looking to fabricate these shapes at some point?
I am probably not fabricating any thing quite as complex as some of the large 3d calamari. But I have a pretty good CNC router and I intend to use Wasp to generate both relief carvings and maybe modular assemblies.
But I’m only just now doing Wasp tutorial #2. I should probably wait to see what else it can do before fully committing!
One very cool benefit I realized about the method I’m using: if, instead of culling the faces I’m culling, i use Dispatch to sort them and set them aside, I can use them later both to split the final form up for modular production, and use their planes to draw labels and create holes for blind tenons on the insides of the junctions.
Really interested to see where it goes.
You can also use Wasp attributes to store different geometry and information you might need for your fabrication, like the geometry of the connections, tags or other detailed info.
More or this in the coming tutorials
Can I set my own collision detection distance? By default, it seems to allow objects to touch if they don’t overlap, which can create non-manifold edges on my single volume objects. Can I specify a small gap?
One of the reasons I picked the penta toroids is that I had experimented with arranging them manually in the past, and their angles created chaos because they just barely don’t loop back around. Wasp managed to find ways to get them to loop back to nonmanifold edge connections that I hadn’t found manually.
yes, objects are allowed to touch by default by Wasp. This because the collider is slightly smaller than the part itself (avoiding to detect a collision with parts it is only touching). Plus, I am using a fast collision detection method, that does not return by default the distance. Modifying the collision distance would lead the part to compute collisions with the part it is attached too, so that is not possible unfortunately.
However, if you want to avoid specific collisions in certain locations, you can use a additional collider, which will be added and used to define additional collision geometries attached to the part. I will make a tutorial on that as well some time soon, but for now, you can take a look at the example file here (the example 4_02_Local_Constraints_Additional_Collider.3dm ).
just a quick note to let you know that Wasp is now working in the latest Rhino 7 WIP.