Automate trimming surfaces with curve using GH

I don’t think both directions is necessary


Panelize_2024_Jun13b_Question.gh (147.3 KB)
I brought in a 9’ wide wall and the last solution seemed to leave out the odd edges, but the red sketch is what i’m after

What if the box is 162 inches wide? (nine feet * 1.5 = 13.5 feet = 162 inches)

In the process of looking at this, I immediately found a bug… Did you see it? Here is a fixed version, adding the expression ceiling(x) twice at the end of the white group:

Panelize_2024_Jun13c
Panelize_2024_Jun13c.gh (149.5 KB)

Now back to my question. Here is what it looks like. How will that work with your proposal?


Panelize_2024_Jun13b2_Question.gh (146.0 KB)

If you can’t see these issues and make changes to the code, you are already in over your head, or “over your skis” so to speak.

1 Like

thank you. i will study until i’m less over my head

good question on the 13.5’ I guess it will have to be decided somehow whether from left to right its full-full-narrow-full OR full-narrow-full-full OR just having the narrow on the side edge like normal. Luckily we like our max wall width to be 12’ for shipping reasons.

Hah, that’s one way to handle the issue. Of course, it will still “fail” in the same way if panels are less that 48 inches wide.

I noticed that colors (and panel lengths) swap ends as the box is scaled, making it inconsistent, so added this orange group. But unfortunately, this “solution” will very likely fail when finished walls have different orientation or openings (reducing area), so this isn’t recommended.

It’s only an example to show that limited test data misses bugs, like the ceiling(x) bug I didn’t see because my test geometry gave the same result for round(x) and ceiling(x).


Panelize_2024_Jun14a_Question.gh (145.1 KB)

P.S. This problem is caused when the two largest faces of the box have the same area, so sorting by area (the aSort component) is indeterminate.

1 Like

Thanks. I have plenty to study on how this works

6 or 7 feet would likely be the minimum width. Certainly never 4’ or less. We’ll do just about anything to change 2 narrow walls into 1 wider wall, or 3 into 2

I was referring to the panels, not the walls. If the panels are ever less than 48 inches, more than three across will fit within 12 feet walls.

Got it

As far as I’m aware, the 48" dim will never change, based on the dimensions of the molds in the factory

The 8’ could grow to 12’ if we order custom, where we would flip the orientation so the long edge of the sheet is parallel to the short edge of wall. We could push for this if most of the walls were 12’ wide, which is ideal for us. Up to this point, we’ve never used a sheet other than 4’x8’. Having the wall be 1 sheet wide max would seem to simplify the panelizing automation/detailing a lot.

Like this? (on a 13.5 feet wide wall)

1 Like

yeah that’s very appealing, especially on our typical 11’-11" wall width

Simple :exclamation:

Panelize_2024_Jun13c2

1 Like

I wonder how much waste would result from 12x4 feet panels?

Here is another idea using 8x4 feet horizontal panels where long and short are swapped on alternate rows:


Panelize_2024_Jun14a.gh (153.2 KB)

There is no off position on the genius switch. :wink:
– David Letterman

1 Like

:joy:

That’s impressive, to say the least.
I’m still working on trying to get the odd width sheet to be in the middle when using the 4’x8’ sheets in portrait orientation
[Panelize_2024_Jun14a_Modified for Odd in Center.gh|attachment]
. Take a look at my mess. My approach has been to use two rectangular arrays starting from opposite edges and working towards each other, each two sheets wide. Then culling one column of sheets (towards center of panel) on one of the arrays, and trying to trim the fat at the sheets that overlap each other. It’s a mess, but I’m learning.

I think the best approach for this is 3 arrays, each one sheet wide. Two are still at opposite edges from each other and pointing towards each other, basically a mirror image. The third array will have rectangles/sheets with widths =4*48-(width of wall) for an wall between 8’ and 12’ wide, and will originate at the end of one of the others to fill the odd gap between. Then no trimming needs to occur.

This may only have the purpose to show that I’m trying
Panelize_2024_Jun14a_Modified for Odd in Center.gh (223.1 KB)

Yeah, I’m staying away from that idea. Looks like you have many unresolved issues… and some duplicate code? My advice is to be flexible, don’t be afraid to abandon one approach for a clearer and simpler one that comes after a long walk or good night’s sleep. Step away from the computer to take breaks :exclamation:

Use a wide variety of test geometry. Keep it “simple”:bangbang: Have fun.

P.S. Looks like you are using an orange group I posted this morning with an explicit warning: this isn’t recommended. :roll_eyes: :question: Better to start with something else.

1 Like

This scenario won’t ever occur because one of the broad sides of the wall always has a lot more cutouts than the other side, so the face that faces down in the casting bed will always be the largest area. I am finding that this part of the component, or something similar, will be necessary to orientate

Yeah, so using the orange group from Panelize_2024_Jun14a_Question.gh is unnecessary, as it tries (in a flawed way) to handle the issue caused by using a plain box for test geometry instead of a real wall section with cutouts.

1 Like

Yes the plain 9 ft panel is a red herring of sorts. Even the simplest panel will have plenty of recesses for lifting/handling hardware and connection embeds

chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/https://www.pci.org/PCI_Docs/Design_Resources/Misc/Sandwich%20Wall%20Panels%20Guide.pdf

Seems to work well for walls between 8’ and 12’ as soon as I added the orange group back in. I’ll have to work on it for walls less than 8’ and more than 12’, as those cases will (for now on the >12’) just use the original single array and have the odd width sheets along the wall edge.

Panelize_OddInCenter.gh (173.0 KB)

I’m guessing you’ll easily break it with tests I can’t think of or execute :grinning:

Also, I’m pretty sure there is repeat code in here, so I’m reading up on data trees

My mistake to post that flawed code (Panelize_2024_Jun14a_Question.gh) and your mistake to use it, despite my repeated warnings.

I see you got the partial panels in the middle, congratulations. I’m sure you learned a lot in the process? But there is no need for three additional EvalSrf and Rectangle components.

Still, you fully own the code now. :+1:

image
Does this use a plain box for test geometry? It seems to be working just by looking at all the faces of the reference brep and choosing the surface with the largest area

thank you and yes, absolutely learning a lot

I am working on this now…one of the EvalSrf uses one of the Rectangle components as an input to get the (1,0) corner to create the Rectangle for the Odd array in the center. There’s probably a simpler idea

Yes. :slightly_smiling_face: The plane is the same, only the location changes, right?

1 Like