On1 - Spacing between multiple sheets (bringing text labels along)

[Zak]

Hello,

As per the title, I’m still using Opennest1. I’ve been having trouble converting my script to ON2. I’m using Rhino Objects to bring text/labels along with my transforms.

My issue comes when I need multiple sheets to cover my parts. I want my script to lay out my sheets with a gap in between, ideally while creating a sheet curve (although this is not entirely necessary).

I can work around this manually, but I would really like it automated. I suppose having this working in ON2 would be a great alternative…

Bringing the text along is critical, as well as maintaining layers through the transformation. Selection by layer isn’t an option due to varying layers depending on use.

I actually need it working on more complex shapes. Previously, it was moving relatively complex shapes involving multiple curves. From my understanding, ON + Rhino Objects changed how it treats the info?

This current file is just the simplest possible version I’d like to get working again.

Hoping this is fairly simple…I’m just learning GH mostly through YouTube and Chat GPT. Have been troubleshooting for 5-6 hours over a couple of days and just going in loops. I was able to get the sheets gaping properly, but then I couldn’t get the geo to move along with it. Battled through lots of duping issues.

I’ve attached my GH scripts before all the additions. As well as screen grabs of what I’d like it to do, as well as my mess trying to get it working…

Thank you so much for any help.

Rhino_Nesting_Test.3dm (149.9 KB)

Group_Nesting_2025.gh (15.7 KB)

[inno]

opening your files and just using it as it is produces good results in my machine:

Are you on Rhino v8? There are many new GH features you could take advantage on to handle layers and baking (the script you attached already succesfully bakes nested stuff on the same layers on which original curves/texts are)

please post the most complex collection of shapes you would like to nest (not in terms of quantity, but sort-of multiple curves contained in a given boundary of some sort?)

[Zak]

Thank you for your reply! I am on Rhino 8. My script is very close to what I need for basic closed curves

All I’m trying to add is that the next sheet has a gap/space in between, and that the next sheet would also be produced.

I find it helpful when dealing with many produced sheets.

I’ve been able to get the additional sheets to gap properly, but not the geometry to follow suit.

Since you asked….In terms of a more complex file, I’ve attached 3: Simple, medium and complex.

Simple

It’s working with relatively simple geometry as you mentioned, so long as things are nicely drawn. Including internal curves:

However, this is where not having a gap between my sheets can become challenging to easily select my sheets afterwards, especially with an offset on the sheet. Don’t get me wrong, I can manually work around this a few different ways, but it would be nice to come out spaced and with a sheet made.

The medium example is where things start to struggle:

It’s not able to properly read the outside of the building. From my understanding, Rhino Objects is/was able to “read” the outside parameter of a set of curves and treat them as 1 “object”? A nice workaround would’ve been to use the yellow road curves as the parameter, as typically that’s the case (while not 100%) although using the actual building parameter would be preferred.

Grouping each building individually isn’t typically an option, especially when there are sometimes 100s.

When I go through layer by layer, selecting objects, converting to lines (to maintain layers) and mass joining, I get a much better outcome, but nowhere near close:

With any split buildings, it can be difficult to go back through and grab what was missing or know what was missed, especially for complex sites.

For this complex site, I can actually get decent building coverage (based on red highlight) but get an error stopping the transformation… which I believe means there’s an error somewhere in the file that can’t be converted… so not quite sure how to address issues with poorly drawn geometry/non closed curves.

Is there a way to have GH “trace” the parameter of each building before trying to nest?

Again, thank you so much for giving me a hand with this.

Simple 2D Site Example.3dm (147.3 KB)

Complex 2D Site Example.3dm (2.6 MB)

Medium 2D Site Example.3dm (1.2 MB)

[inno]

ok, for instance, this is the file with Complex curves, and these are just the building curves in the layer 0build:

do you want to get the total outline of each block, like this?

or the single recognizable/splittable entities, like this?

the weird and interesting thing is that building blocks are already a sort of nesting of the single buildings that belong to it

so maybe it’s enough to nest the building-blocks, but at the same time move all the inside curves that identifies single buildings together with those

the precision and effectiveness of this operation depends 100% on the quality of your original curves… and there’s just little to say about this [see second part of this post]
if lines are not somehow creating a closed boundary, then it will not result in a closed area (GIBO concept )
like for instance these parts are not recognized as being closed shapes no matter what:

so, in principle, it could be something like:

GH file to be opened together to your complex Rhino file: Complex_nesting_3.gh (32.2 KB)

---

there’s an idea I have seen around in this forum being used a few times, sometimes it worked, sometimes it didn’t to try to make closed curves out of intersecting lines

the main principle is like, explode everything, map any single line by its start and end points, then take all the end points together as a flat whole list of 3D points, and use something like Pufferfish’s cull duplicates with “Leave one” or “Average” (and play with its tolerance)

at that point you pull start/end points of the original Lines to these new set of unique “merged” points, and pray that you find the right Tolerance to make closed loops out of everything I think it’s worth a try!

[edit: it worked on some areas! but you need Pufferfish plugin… not sure how to do that in Vanilla, maybe averaging Point Groups is the fastest way to vanilla that?]

Complex_nesting_3a.gh (31.4 KB)

[Zak]

…Woah… That’s amazing…

First, thank you again for looking into this for me and providing explanations! I knew this should be possible, but seeing it almost working like this is so cool!

A few questions:

This seems to capture almost all the perimeters other than …

Which is funny because in 3a it’s not picking up the diagonal lines but can pick up the other larger ones…

I don’t draw the buildings myself, so can’t always guarantee they’re perfectly drawn/closed. Although being able to identify which aren’t closed via the highlight is also very helpful. It seems the green perimeter is almost 99% perfect, though.

I’m happy to include Pufferfish if it would solve the problem. How does it work?
What is GIBO concept?

I’m trying to get all the interior curves and texts moving as well. Like so:

When currently baking 3a, as you mentioned, we’re only moving the 0build layer, but I’m only getting the perimeter.

If I want to keep objects on their layers during translation, would I add them here?

[inno]

@Zak

What is GIBO concept?

I mispelled it’s GIGO, Garbage In Garbage Out
when you find yourself in the situation of having to deal with garbage input data, you generally might expect to also get garbage output data

@Zak

I don’t draw the buildings myself, so can’t always guarantee they’re perfectly drawn/closed.

I know these kind of input data is always bad for one reason or the other…

I have a question that might have an obvious answer… but there are relevant implications: are you going to lasercut this stuff?
in particular, you want all the inside-curves to move and be nested together with each building-block because you want to laser-cut also those into smaller fragments? or you want to just laser_etch/engrave their contours?

I ask this because laser-cutting/engraving open curves (expecially multiple overlapping fragments) might not be the best choice…

what were you planning to do exactly with this nesting?

---

this updated definition would do the following:

I first deleted the Layer 0road from the Rhino file

Complex_nesting_4.gh (37.4 KB)

A: references items from a Layer of your choice (in this case 0build) and uses the closed building-blocks-regions it can recognise (also using the dirty trick) to define the big shapes to be nested

B: takes EVERYTHING from any Layer in the Rhino file that starts with 0, and

C: organises those items into branches of a data tree like the one with the shapes in A (using closest point matching)

D: is the layer that contains the curve that defines your sheet size, a single rectangle

E: nests only the building-block-regions found in A

F: takes anything from C and Transforms those with the very same Transform matrix of its closest building-block-region

G: bakes a copy of the nested geometries/text/whatever was in the Rhino file in a layer starting with 0, on the very same layer, but nested

so when you press the Bake button in G, every single item will be duplicated in its nested orientation, there will be two of everything

the result is like:

---

brief explanation on what could be perceived as random stuff:

WHY ARE THOSE CURVES OUT OF THE SHEET?!?!?!?!?!
Those curves in the original drawing are not contained by any of the building-block-contours, they lie externally on no-one’s land:

so, after the Nesting, they Transform together with the closest building block contour despite -of course- not being part of it

the external curves closest to the top nesting area will move with the top part, the ones closest to the bottom area will move with the bottom one, as if they were chained like this:

same thing happens here with those long offsets, and all those tiny bits

here is the starting situation:

and here the final:

those “additional external shapes” might indeed intersect with other areas… because for the Nesting we don’t even consider those, we only nest building-block-contours, and those do not lie inside any contour

[Zak]

…Oh my goodness. I’m floored. This is wild. Thank you so much for the explanation. This is obviously waaaay over my understanding and will take some time to study how each component is working.

Ahh, that explains why googling Gibo was confusing . (“Garbage In, Biomaterials Out” lol although not far off, I guess)

To your questions of: “What am I actually doing here?”. No, it was not obvious, and I hadn’t actually mentioned it. My intentions are to achieve three to four things overall.

The first, which was generally working in ON1 was for laser cutting+etching single/simple curves (parts of buildings).

What you did here was to be able to nest all of the buildings onto a sheet for regular printing/plotting. Most buildings are currently being made by hand in a variety of ways, but the nesting of the buildings on the sheet is being done by hand/manually, which can take a while for large sites.

The two other things I’m working on are:

1. You were onto the right idea about trying to laser-cut each part, but not using a laser cutter. It’s uhhh a big foam cutter . Similar idea, though, basically cutting 2D Curves with similar limitations, you don’t want to be cutting a bunch of parts too close to each other/ontop of each other as per your concern, amongst other things.

   First idea would be to be able to take a single building i.e. :

   

   And then trace/ split the building up in parts like either A and/or B

   

   I think it’s possible to apply simplifications (through area calcs?, +/- X heights, etc) to a more complex building and then have those shapes traced and laid out. (This would be because some small details aren’t suitable for fabrication due to their size, for instance.) So automating simplification would be wild. A building such as:

   

   Could be simplified to…

   

   Potentially using some dim discrepancy, area calculation, and +/- heights to “decide” what to keep/ how to simplify. For instance, the small mech boxes ontop or the narrow 130 sections

   

   In theory, could an advanced version be able to “read” the heights and potentially average them? To recognize that the largest area is 148 and that the total area of each of the small boxes and the small 130 “collar” are to be averaged into…

   

   By using sliders to input: % area difference, the max height difference to avg, etc.
   Is this even possible or am I starting to push the possibilities of GH?

   And 2.

   Much simpler than 1. Also, for the large foam cutter. I got partway through this one, but couldn’t get it quite working. I’m essentially trying to sort and then nest single shapes.

   So, either on simple sites, all the buildings can be “read” and then nested onto sheets based on their label (heights). So all the 8s nested, all the 13s nested, and so on.

   At the basic sense, this:

   

   Proper nesting would be a bonus, but could also be done on its own afterwards.

   Or for more complex sites, going through the prev script first to break up the building into functionally sized/simplified pieces and then nesting them. Ideally, with some labelling at this step or in the previous one at the splitting up (B1.1, B1.2, B1.3 on each separate part of a building (B1)).

   

   The ultimate goal is nesting all parts of all buildings based on their heights while mainting some labeling/ part origin history to put it back together…

   So all the 10s from various buildings would be nested/boxed together so they could all be cut/exported together quickly at the same time but then they would be labelled as to what building they belong to (B1, B2, etc).

   I’m just learning GH but I thiiiink this should be possible.

[inno]

this looks like a very different thing than the original problem

the first approach that comes to my mind is to

1. organize a data tree by building-block
2. extrude each building contour in direction +Z by the amount in the text height-value inside each contour (point in curve or pull point to relate those to each other)
   → each closed contour must contain a height-value
3. use Contour to get cutting curves
4. use Clipper/RegionUnion to join together neighbor-shapes of the same building block at the same Z layer
5. when the building-block data-tree is well organized, naming each curve is a very easy job
6. I would also consider projecting next Z-layer curves over the previous one and engrave those, in such a way to have a reference of where/what is going to be glued on top of each shape (which will make your life incredibly easier when assemblying the whole thing layer by layer)

but note: this would require an additional “layer of cleanness” in the drawings, meaning the layer which contains the height-text now has some polylines in the shape of arrows (rooftops on an angle?), many “not-just-numbers” like “angle in88to61”, and not each building contour contains its height value
regarding the 0build layer, lines/curves must really meet together in such a way to create closed areas, which is something you can try to correct with dirty trics, but doesn’t assure everything will just work fine without manual intervention on the drawings

[Zak]

Yes, for sure. Kind of long-term plans there. And I am nowhere close to that, but hoping to learn. I just came to the forum, trying to figure out how to space my ON1 sheets

We’ve gone pretty far from the original question.

I should clarify while I could split a building into a bunch of slices (contours), however the intention to cut them more like tubes (then can be cut to length in a variety of ways, that’s part ofa later challege to nest all parts of given sizes), or with some layering ontop of each other as needed but more to the sides.

Like so:

I suppose it could be possible through contours and RegionUnions to identify the change in height which would correspond to the “max geometry” of a given profile? For Instance, in the building above, where the Geo would change at 42, 71 and 82 and then identify - > nest those curves aside.

So not so much layering a bunch of say 2” layers together.

But interms of your breakdown:

1. organize a data tree by building-block

This is where my learning of GH is at lol learning how to organize my data.

I also typically have access to a 3D modelled version, extracted from the 2D. I just wasn’t sure if sorting the geometry was easier in 2D or 3D. Which, I guess due to the 3D being better geometry (Actually closed) that might be better suited for that purpose?

4. use Clipper/RegionUnion to join together neighbor-shapes of the same building block at the same Z layer

That was something I wasn’t sure about.

I’ve seen a video about using the contouring method, but I don’t believe it covered RegionUnion, so I’ll look into that. I was also concerned that the contouring method might miss small details. However, I suppose just setting a small enough

6. is a great point, however, with the foam cutter, engraving isn’t really an option, unfortunately.

This will take some time to get through, but I appreciate your written instructions. It’ll give me something to work on.

Solving the mass nesting of buildings still seems like magic when I look at the file, to be honest. Really shows the power of GH in the hands of someone who knows how to use it.

Thank you so much for your help with this!

[inno]

this could be a starting point for the “big foam cutter” thing and processing the boundaries:

it reads “perfect data” organized in layers like:

and spits out infos and cutting curves like:

it merges together different building curves up to their heights (it does that geometrically, with extrusions, which are pretty cheap and fast)

the H (Height) is useful because could allow to nest together parts of different Building Blocks (BB) that share same height
but the thing that you can’t hetch/engrave stuff on the parts being cut is a big drawback because you’ll need to somehow label those…

I did not test this extensively… but could be a starting point

this is the Rhino/GH file from the above screenshots:

regions_and_heights.3dm (84.3 KB)

cutting_curves_from_regions_and_heights.gh (27.9 KB)