Hi! I’m pretty new to grasshopper and i’m struggling to figure out which components to use to filter a list of surfaces into several different categories depending on their number of vertices. Can anyone offer guidance on this matter?
Cheers!
Sure:
I’m sorry if I’m being thick here, but I don’t understand. Am I asking the question incorrectly for this forum?
This version results in the branches being sorted by number of vertices:
sort_vertices_2018Jan31b.gh (13.4 KB)
Somewhat, it would be nice to have a picture of your surfaces, or even a file. See, words like “filter”, “surfaces” “vertices”, and “categories” all have various meanings and since you’re new to GH it’s unlikely that you use them in the same way as the rest of us would. You might call meshes surfaces because mathematically they are. And you might call control-point vertices. And you might say filter instead of sort, or cull.
So we know very little without any files and what little we do know we do not know for sure. It’s hard to answer a question like this.
I see, thank you both for your time and replies. Although I don’t fully understand Joseph’s definition above I don’t think it is the solution to this issue, my fault for not being clear enough! Hopefully this screenshot and incomplete definition will help illustrate what I’m working towards here. I’m trying to separate a collection of planar NURBS surfaces into two or more collections based on the geometry of each individual surface. I’m more interested in learning how this works than simply obtaining a working definition.
sortlist.gh (10.9 KB)
Here’s how my code works with your “data”:
sort_vertices_2018Jan31c.gh (24.7 KB)
@Michael_Pryor’s version is simpler because, using Dispatch, it handles only two different polygon shapes, as per your model, whereas mine was happy sorting/sifting a wide range of shapes with “3 to 10” vertices into branches of the “data tree” (final results).
2 Likes
I see! Thank you so much for the explanation. Everyone has been very helpful! It’s become clear to me that I need to study more. I am using this to create augmented polyhedra with variable augmentations.
Looks cool. If you had posted the actual GH code file with that screen shot, we could show you how to simplify it further, to avoid so much copy/paste. Hint: three sliders, grafted, feeding one copy of the code on the right.
Like this:
sort_vertices_2018Jan31d.gh (21.1 KB)
1 Like
When you first posted I set out to simplify it. This is what I came up with!
Augmented Polyhedra-2.gh (36.9 KB)
That’s pretty close, good job! But your don’t need the BANG! (Explode Tree):
Augmented_Polyhedra_2018Jan31a.gh (38.6 KB)
And of course the vector from 0,0,0 only works when the polyhedra is centered there, whereas your earlier code (and mine) used each surface’s normal vector.
By the way, instead of Area C (Centroid), I use Avr (Average) of each surface’s vertices because it’s much faster. Makes a big difference when there are many surface.
Here is your “Truncated Disdyakis Dodecahedron” moved away from the origin. One can learn a lot about data trees on a model like this. Thanks for the fun.
sort_vertices_2018Jan31e.gh (44.7 KB)
P.S. Notice that in this case, the way they are being used, Entwine and Graft are doing exactly the same thing.
1 Like
One can learn a lot about data trees on a model like this.
I went and rebuilt your definition here piece by piece examining how it affected the data. It was really interesting to see how the different components altered the structure (had no clue what PShift did before that). This is really cool stuff. It makes sense that the Average would run faster than Area Centroid. We don’t need the Srf CPnow that we are working directly off the Normal vectors. I tried to do that when I first started but couldn’t figure out what to use for the uv input on EvalSrf . Your example above made it much more clear!
Thanks for the fun.
Thanks again for your help, this was enlightening. If you’re ever looking for models of polyhedra, Rhino Polyhedra is a fun and great plugin that I will play with when consumed by boredom or find a project that requires it.
Cheers!
Augmented_Polyhedra_3.gh (35.7 KB)
Well, actually, I’m a little surprised this works without Srf CP. I used it in my version for good reason. “World XY” points are not the same as surface uv points. You can see that by comparing these two Pt parameters. The points from EvalSrf (in green) are far away from the actual surfaces. That it works is a quirk really, and it would fail to return the same vectors if those surfaces weren’t flat. Really gratified that you have learned so much from this though. Well done! Cheers.
