I’m working on a project with a lot of vacuum formed parts.
I made a little script that takes SubDs, finds their minimal bounding boxes, and gives me the option to split the subDs in half along any axis of the bounding box. (red = input subD, green = output split subDs)
The crease and corner crease inputs on the SubD from Mesh component are giving me unreliable results.
-What makes this component decide if a vertex is a corner or not?
-Also, is there a reason it doesn’t accept boolean inputs?
-Also, important: Is there a mesh component, native or plug in, that can crease mesh vertices so I can feed the SubDfromMesh component a pre-creased mesh? Or maybe a way of tagging mesh vertices as "corners? If I could do that, I could maybe only crease the vertices that intersect the splitting plane?
Here’s the definition. Thanks to @Helvetosaur for the minimal bounding box component.
Minimal Bounding Box Splitter.gh (41.4 KB)
Here’s a C#-script for creasing meshes:
For your question about which ones are “corners”:
But as you can see in the picture, there is no good way to tell grasshopper from corner A and corner B. since corner A is a round one determined by your shape, and corner B is not round due to the split.
Also there is some problems with mesh split, I tried both GH and rhino and rhinocommon commands:
There will always be some annoying n-gon:
For my GH file you can test these multiple options on “Mesh to SubD”.
The vanilla components only offer 3 options while in rhinocommon there are 8 of them.
Sorry I missed something in the previous reply. I deleted the related image and GH file in the last reply.
Uploading: update on corner.gh…
Here is the update:
As for the unexpected N-gon thing, there are also some possible ways using C# in rhinocommon, please wait for some time.
update on N-Gon problem.gh
N-gon problem solved.
I think for now this is what I can do.
I had to split these mesh faces manually to prevent N-gon along the split curve.
I am sure there will be better ways, or more elegant ways. I will update here as soon as I got one.
Thanks for working on this.
I think part of the problem is that Rhino and especially Grasshopper are not yet n-gon friendly in many circumstances. There are a ton of Grasshopper mesh components, for example, that automatically triangulate Ngons that go through them and there’s no option to prevent it.
I’ve said before on Serengeti threads that Rhino 8 and Grasshopper 2 need to seriously address Ngon incompatibility issues, because SubD very frequently needs Ngons in order to achieve certain forms. Ngons in SubD also have a lot of very fun applications for discovering new and interesting forms.
I would have hoped to be able to use an intersection component to tell GH to crease corners that were on the split plane, and to leave other corners alone.
I think “intersection on subD” is too special for a GH component.
But N-gon should be implemented as some basic components. because in rhinocommon N-gon are really difficult to use.
Not like T-spline, SubD will use more N-gon.
“There are a ton of Grasshopper mesh components, for example, that automatically triangulate Ngons”
In fact, there are all tri and quad meshes, there is no N-gon in a mesh structure.
N-gon is implemented in Rhino using this kind of structure:
1: How many N-gons are there in the mesh? lets say M
2: For each N-gon in all the M N-gons, which faces(tri and quad) constructed them? For example, “No.2 N-gon” use “number 34,35 and 40 faces”, “No.10 N-gon” use “number 50,51,53,64 faces”
3: For each N-gon in all the M N-gons, which vertexes are involved? For example, “No.2 N-gon” use vertexes number 100,102,103,104,106,107.
So they are all about tri and quad, N-gon is just treated as additional informations on some “cluster” of faces. and in the last step of mesh construction, these special faces are combined as one.
But deep in the base, they are all tri and quad.