TrimQuestion.3dm (829.3 KB)
TrimDesired.3dm (961.9 KB)
Not a Grasshopper question?
With this approach, the other thread was a complete waste of time. 
Geometry is internalized (cyan group), no need for Rhino file.
Send me the bill! Thank you again. I tried to hide, but you found me
I’ll stop moving the goal posts when I’m smart enough to know where they are.
The question you ask determines the answer you get.
Dan Manning
Unstated assumptions: In the 1976 film, The Pink Panther Strikes Again, Inspector Clouseau, seeing a small dog inside an inn asks the innkeeper “Does your dog bite?” The innkeeper says, “No.” As Clouseau reaches to pet the pup, the dog leaps into an attack biting the Inspector’s hand. “I thought you said your dog does not bite.” The innkeeper deadpans, “That is not my dog.”
NOTE: surfaces in different planes may cause this code to fail…
This was a lot of work, dealing with surfaces on three different planes. I thought I was done before the purple and orange groups, but noticed little details as I looked closer. 
The purple group compensates for a peculiar mis-alignment of the EvalSrf ‘F’ output that places the “origin” slightly outside the boundary surface. You can see the issue by connecting ‘F’ (instead of Pl Origin) to the Rectangle ‘P’ input.
The orange group is optional, trying to handle differences between where the 48X96 surface edges cross the two holes in each surface. Not sure what’s going on there?
Those holes are wall openings (windows, doors, etc.)
This will be useful for handling walls on different elevations simultaneously
Again, thank you for the effort
It is still flawed. Doesn’t always work correctly with surfaces at arbitrary angles. 
Too many “moving” parts so I created all surfaces in the XY plane (white shapes) before rotating them arbitrarily. So this entire light cyan group only creates and positions surfaces.
The “paneling” takes place below, in this code. The white group does nothing in this case but I left it in, just in case it is required by some surface shapes.
based on your advice Joseph, i’m going to give more information than my intuition tells me. Hoping that is what you were conveying and that I didn’t miss the point, but I’m not confident…
-the 4’x8’ panels are made of rigid foam insulation (3" or 4" thick)
-they go between two precast concrete wythes (3" to 5" thick) to form a “sandwich panel”, or precast insulated wall panel
-there will be full-depth penetrations (called “blockouts”) for windows, doors, scuppers, etc.
-there will also be partial depth penetrations where the concrete portion has to be thickened (and, in turn, insulation thinned) to make those parts of the wall panel stronger, such as at the locations where the (up to) 70,000 lb. panel attaches to the floor members or roof members of a building
https://www.grasshopper3d.com/forum/topics/getting-the-exterior-and-interior-curves-from-surfaces
I found this post, and I’m trying to get the 2d geometry of full penetrations vs. partial penetrations vs. outer border of the insulation shape (before panelizing) to be able to eventually control a CNC machine that will cut each sheet of insulation
The ultimate goal for me is to take an insulation layer from a 3d Tekla model (full size, prior to panelizing), panelize it into surfaces with full-depth shapes cut out (like you’ve already helped with) , and have surfaces of the partial-depth penetrations (organized by layer, or some other way to differentiates the various “partial” depths that occur within a single wall) overlaid on those individual insulation panels. With that we can create G-code files for the CNC machine that cuts the insulation
My next approach will be using Make2D from the brep, or from individual faces of the brep, since it can separate Visible Curves (full-depth penetrations and outer edges) from Hidden Curves (partial-depth cuts)
SampleBrepsForPanelizing.gh (1.5 KB)
Your GH file is empty - no internalized geometry?
And I see that my last two posts were apparently useless?
SampleBrepsForPanelizing1.gh (108.3 KB)
sorry, forgot to internalise.
and no, the last two posts weren’t useless, but I used the one i remarked as solution since it is simple enough for me to understand. I’m sure that when I use it for walls that have different orientations i will run into the same flaws that required the later, more complex solutions. When I tried to use the more complex ones i ran into issues with my lack of understanding (which I’m sure is the problem, not your fine work), which I should have documented, but didn’t as I was scrambling to wrap my head around this task, for which i am out of my league
I’m lost, sorry.
to reiterate and simplify:
-i’d like to get separate curves from the brep for the outer boundary (wall edges), full-depth penetrations (windows, doors, scuppers, etc.) and the partial-depth areas
-these curves would be fed into the panelizing solutions you already so kindly provided
-Make2d can separate the hidden curves from the Visible curves, but it projects the curves onto the XY plane, so I may have to “transform”/move and rotate from the XY plane to a plane where the panelizing tools (rectangular array and surface split) can operate
-after the panelizing is done using the wall edges and the full-depth penetrations, the idea is to overlay? the curves representing partial depth cuts on each panel (after initial panelizing) to create G-code for cutting each panel
I tried once to use Make 2D - struggled quite awhile with it before giving up in disgust. My opinion of that component is extremely low.
Again, I’m lost.
yeah, i think a better way may be to get the curves from the bottom face (if lying flat on a table) of the brep, where if there is a hole it is a full depth penetration, then get the curves from the top face, where holes could be either full or partial depth. If overlaying them any on the top face that match the bottom face must be full depth, and all others would be partial. Make2d won’t work because the view (top, front, perspective, etc) would change depending on the orientation of the panel. Each brep is referenced directly from a 3d model, so they come into Rhino at different locations based on where they occur on the building, and the coordinates of the origin in the Tekla model.
the challenge i’m facing is to generate these curves where they are in the correct spot to be useful for the tools you created
I’m not following your details at all, sorry. Might help if you posted an image of what you’re building as I still have no idea? Must be large to consist of multiple 4 feet by 8 feet panels?
Your original thread suggesting SubSrf (Isotrim) got me started on a path using UV isocurves, which have many problems. This effort has none, it uses a completely different approach.
The light cyan group at the top creates test geometry, the actual work happens below that.
P.S. I found and fixed an error in the ‘test geometry’ group at the top. It can be difficult to do correctly, without modifying the expected data tree structure (one panel per branch!).
P.P.S. Found a bug… Here is a fixed version, adding the expression ceiling(x) twice at the end of the white group:
Panelize_2024_Jun13c.gh (149.5 KB)
So far this is working really well. Thank you again Joseph
Good.
It might be possible to carefully refactor this code to expect multiple panels per branch. There would need to be a good reason for me to tackle it though, such as one branch uses 48X96 inch panels, another branch uses 48X48 inch panels, a third branch uses 36X36 inch panels, etc.
There can always be more. That’s software 
On second thought… I guess you’re asking (privately ) for the under-sized panels to be in the middle (in both directions?) instead of along an edge? Sure, it’s possible, somehow.
7. This is not a do-my-work-for-me group
