I am new to grasshopper so apologize in advance for clumsy scripts and inaccurate terms to describe my problem. My task is to create a dome with many hexagons and some pentagons (around 2100) that I am planning to fabricate out of laser cut paper.
I based the dome on this script below and added some scripts to make the hexagons more equal to each other ( although there might have been a way to do it within the original script.):
I am now at the stage where I have divided the hexagons into groups of 50 and unrolling them and creating a pattern that adds walls that can be folded to create walls to connect the hexagons. Uploading: IMG_0625.jpg…
However when I unroll the hexagons some hexagons unroll in the wrong direction, I believe either because the starting point in each hexagons vertices are different or because the direction (up/down) of each surface is not the same. This also causes the number tag which I offset from the polygon center to not fall on the “tab” in the cases the orientation changes, I am sure there is a better way to specify the point for the tag to fall on the tabs that works more consistently but couldn’t figure it out.:
Is there a way to unify the starting point, or orientation direction so they all unroll in the same vertical alignment. In an ideal scenario the unrolled surfaces would also line up in a similar layout as the source of the grouped hexagons, rather than along a curve.
Without those plugins, I can’t do much with your GH file but I can write simple GH to check surface normals by getting all the hexagons from the Rhino file like this:
By the way, it occurs to me that you don’t need “unroll” for flat hexagons when Orient would work fine. Then I noticed in this part of your code that you do use Orient:
As in the GH file I posted, the center of each hexagon for EvalSrf is the ‘uv’ point ‘0.5,0.5’, not ‘{0.5,0,0}’ as you are using - and the ‘S’ input must be reparameterized
You are using P Center needlessly because EvalSrf gives you that point on the dome, and you already have the ‘World XY’ point as the Orient ‘B’ input. It’s always better to use these points you have rather than getting them again from P Center or Area ‘C’.
As I said, there isn’t much I can tell from your GH file without your plugins but I see various things I would do differently.
The white group splits the list of hexagons into branches by section (from layer names), then sorts the branches by section names using one line of Python:
a = [x for _, x in sorted(zip(x, y))]
I then spent way too much time trying to sort each branch/section so labels (and hexagons) were in some kind of logical sequence, using To Polar in clever ways… It worked well for sections near the bottom of the dome but less well as the sections increased in Z. Finally, I ripped it out, not sure if that’s really possible or wanted?
The green group are the hexagons you want to Orient using the same planes used for the Text Tag 3D ‘L’ input.
P.S. On the other hand, it doesn’t make much difference for Orient ‘A’ (Source) if you use EvalSrf ‘F’ (shown below), Align Plane ‘P’ output or PRot ‘P’ (Rotate Plane) output.
Hi Joseph, thank you so much for these feedbacks! The last solution in the orange boxes works really nicely and it helps that I don’t have to duplicate the code over and over but can just plug them all in. I did have the goal originally to sort the tags in a more logical way but I gave up on the idea as I also wasn’t sure if it was possible, and in the end not completely necessary as long as I use the screenshot of the 3d as a reference map.
One issue I still cant figure out, which is probably a very basic task, is how to have the tags placed on the tab of the hexagon (not in the center) my solution of offsetting the tag in the y direction works until some hexagons are flipped and the tag lands in between the tabs.
