Trying to make hexagonal pyramids on surface unable to generate suitable cull pattern

I am trying to make hexagonal pyramidal spaceframe structure using a double curved surface. I only want to join the vertices of the hexagons to the green project centroid. I am unable to generate a suitable cull pattern for choosing the vertices to join with the projected centroids. Please help.

CULL PATTERN PYRAMIDS.gh (68.8 KB)

Like this?


CULL PATTERN PYRAMIDS_re.gh (67.7 KB)

1 Like

I skipped the partial hexagons along the edges.


PYRAMIDS_2019Nov21a.gh (29.2 KB)

Adding a surface to the pyramids with points sorted along circles to ensure consistent surface normals.


PYRAMIDS_2019Nov21b.gh (32.5 KB)

1 Like

Aha!! So the culling should be done in the beginning itself rather than later on. THanks!!

Yeah partial hexagons aren’t to be used. I am only concerned about the full hexagons.

Thanks for sharing the script. I see some new components in your script that I haven’t seen before. So much to learn even to generate regular geometry like this!

What is the function of the following components here?

Sort along curve, ( and what is the purpose of reversing the output points? )
Average ( I believe to find the centroid of the hexagon, right?)
Closed (What is a closed and periodic curve and what are their purposes?)

Sort along curve sorts the six points for each hexagon “along” (around) a circle that was created in the center of each one. It ensures the points for each hexagon are sorted in the same sequence. Reversing that sequence has the effect of lofting the resulting lines in reverse order which flips the surface normals of all the pyramids. Try it.
P.S. Oops, I used reverse twice, once on the output of AlongCrv and again on the input to Loft. Disabling both is the same as enabling both… my mistake.

Average gets the center point of each group (branch) of six points.

Closed returns True for the complete hexagons, False for the partials along the edges.

P.P.S. The white group below indicates how/why Cls (Closed) works to separate edge fragments from the complete hexagons (closed curves) in white.

1 Like

Here is a different way of separating the complete hexagons vs. partials on the edges. It compares the area of each SrfSplit and keeps (culls) only those that are greater than their average area.


PYRAMIDS_2019Nov21c.gh (34.1 KB)

1 Like

Okay. Thanks for your detailed explanation. :+1:

I made two alternatives continuing further on my original script. Need your opinions and advise.

i) Without using the average component and discontinuity of the curve.

ii) Just using the extrude to point component to create the loft. It saves steps of sorting points, then using the loft component.

I am comparing the option (i) with the ones you shared. Why are we dismantling the vertices of the hexagons via closest points component and recreating the hexagon closed wireframe again?

24TH NOVEMBER_HEXAGON PYRAMIDS_REBUILT FROM SCRATCH.gh (83.9 KB)

I think I explained what I did as best I can. It’s all in the code. Can’t see your current file in R5.

missing

P.S. As I recall, the curve segments you supplied were not organized as hexagons, so Closest Points was used to group six edges near center points and then check to see if they were “Closed” when joined, meaning they are valid hexagons vs. edge “garbage”.

1 Like

24TH NOVEMBER_HEXAGON SPACEFRAME_REBUILT FROM SCRATCH_revised for forum.gh (93.2 KB)

Here’s the revised file. I have internalized the hexagonal structure curves I got from Lunchbox. I have removed relays.

The evaluate surface and multiplication are native grasshopper components.

I agree, they were not organized as hexagons. The split surface component creates hexagons which, when ‘debrepped’ give curves arranged in branched data of six items each.

Please, PLEASE remove that 5 MB screen shot image!! It freezes my browser.

I’ve already played with this project and see no reason to look at it again, esp. considering the extra effort required to see it in R5.

P.S. That image is insanely HUGE!! 34080 X 10390 pixels. CRAZY!
This is an important skill to master so some comments:

  • At full size, the components appear far larger than normal in Grasshopper.
  • PNG is often a better format than JPG for this. If there aren’t too many colors, an “indexed” PNG with only 256 colors can be much smaller yet still effective.

For example, here’s your image scaled to 10% of original size (now 3408 X 1039 pixels). At full size, the components look approximately the same as the Grasshopper canvas at 100%. I also indexed this to 256 colors, which loses a little bit here but isn’t bad? Most importantly, it’s only 150 K instead of 5 MB! That’s 1/33rd the file size.

Done. I removed that image.

In future, how can I make my Rhino 6 Grasshopper files backwards compatible so that it is easier to view for people using Rhino 5?

Whether by design or negligence, compatibility between R5 and R6 is pretty much a one way street.

These are the most significant GH obstacles, in my opinion:

  • Referring to geometry in R6 .3dm files which cannot be opened in R5. Internalizing geometry in the GH file gets around this.

  • Subtraction, Multiplication and Evaluate Surface. If there aren’t too many of these and they aren’t hidden inside of clusters, providing a readable screen image of your GH canvas (no dark backgrounds please) allows R5 users to make repairs and run the model. But doing that more than once is a pain.
    There is a way in R6 to use R5 versions of these components but I can’t find a reference at the moment. Making these three simple, commonly used components incompatible between R5 and R6 effectively burned the bridge between versions.

  • Relay is a new R6 feature that functionally amounts to nothing more than an R5 “Geometry” or “Primitive” param component with ‘Wire Display’ set to ‘Hidden’. :man_facepalming:

Beyond these issues, there can be subtle differences in behavior that show up in some complex models, requiring R6 fixes to R5 models that are not backward compatible.

The monster screen image yesterday wreaked havoc with my browser but I just took a look at your changes now. Yes, Extrude Point (Extr) using the hexagonal sub-surfaces is a much better solution than lofting lines because the bottom edges are on the original surface, without gaps. And extruding surfaces results in “Closed Brep” pyramids, which is generally a good thing.

Here is a revised copy of PYRAMIDS_2019Nov21c.gh using Extrude Point instead of loft. Nice!


PYRAMIDS_2019Nov25a.gh (26.9 KB)

Your method of culling complete hexagons based on distance of centers from surface edges works fine too, along with the two other methods I used.

1 Like

You write these black boxed text using the kbd tag or is there an alternative way too?

Yes, and no alternative that I’m aware of.

<kbd>Subtraction</kbd>, <kbd>Multiplication</kbd> and <kbd>Evaluate Surface</kbd>

1 Like

Okay. Thanks again. :slight_smile: