Because of SubD coming to Rhino 7, and because the least processor intensive way to work with SubD in Grasshopper is to work with meshes and convert to SubD at the end of a definition, Grasshopper 2 needs to have better support for Ngon mesh faces.
Maybe the native grasshopper mesh components that currently automatically triangulate ngons could all get an additional boolean input that toggles between true to triangulate (default), and false to not triangulate? (of course I’m not a mesh or grasshopper expert, so maybe there’s a reason not to do this that I don’t understand?)
In SubD, it’s often justifiable or even desirable to use some Ngon faces.
I’ve been experimenting with using Grasshopper to create meshes for conversion to SubD and I keep running in to obstacles when my meshes have Ngon faces.
A bunch of current grasshopper components, including some essential ones, seem to automatically triangulate any mesh face with five edges or more. This happens even on planar Ngon faces. Components I’ve seen do this include
align vertices and others.
The only workaround I’ve found in GH1 for joining Ngon mesh faces is:
mesh brep and then using a ghpython component to call “_AddNgonsToMesh”.
Slow but it works. And of course it only works on planar Ngon faces. For SubD, there are a lot of circumstances where you might also want nonplanar Ngon faces.
Anyway, using this workaround, and using a very basic application of the Wasp plugin’s stochastic aggregation, I’ve been able to create some fun SubD objects as an initial exploration.
A running joke I hear about grasshopper is that we just make tagiatelle with it. I think this looks more like Calamari:
This is a single closed volume. On the left, mesh. Each module is 20 faces. On the right, converted to SubD. And yes, this is just playful blobbing, but there are clearly more practical applications for a workflow going from meshes with ngons to SubD.