I need to nest panelized pieces from boards, on sheets that are made from boards as well. similar to this image.
therefore i have a lot more reduced search space, since the boards need to align together. translations on Y direction can happen every N unit (steps) and rotation is also bound to 0 or 180 degrees (which is already implemented in the solver).
so far I can nest my parts in this way, by post processing the initial nest and re-aligning the parts after nesting. Would you know of any way to implement this constraint in the nesting algorithm?
Seems to me your best bet is automating this post processing step. Hard to see the difference between āwrongā and āidealā nest, though I guess you move both pieces vertically to make board seams even, top and bottom? Individually or move them both together? Do you really need OpenNest at all for this?
sorry if it wasnāt clear:
in the ideal nest, the board seams from input geometry and sheet are aligned together. where in wrong nest they are not.
yes in this case. they can be moved individually or together. I think in the algorithm it happens individually.
this was a very simplified diagram to describe the question. I am dealing with many many parts and i prefer to use a nesting algorithm. in this case i am using OpenNest since I can integrate with grasshopper.
I have the post-processing automated; but a drawback of this workflow with nesting first and then post processing it, is that sometimes the initial nesting can be so packed that the post-processing wouldnāt be able to find ideal position for objects in one sheet and Iād need to move the geometry from one sheet to another. therefore not a very optimized process.
How does the input geometry have board seams? Looks like a chicken-egg scenario to me. Asking quite a lot from OpenNest to align board seamsā¦ If the seams on the input geometry were rotated 90 degrees then OpenNest is supposed to only use the same orientation in layout solutions? Does setting āRotationsā = 1 do that for you?
P.S. Here is an OpenNest model from three weeks ago to experiment with:
With āRotationsā = 1, OpenNest fails to fit the big rectangle at all unless itās rotated 90 degrees, which does make sense, eh?
I agree this is asking quite a lot from openNest. I donāt know of any way to get the result I want with the existing solver, but I was hoping to get some suggestions. In my understanding this means reducing the search space (or discretizing it) based on the boards.
For example in this post, imagine that the piece couldnāt be placed on all the possible options, but only the ones that would fit the board seam criteria.
Iām not quite sure why it would be a chicken-egg scenario. I am making a part (out of wood boards) that I need to control the seams for construction/structure purposes. And I am doing a CNC milling from sheets that are not plywood (homogenous) but rather made from Boards. So Iād need to nest the pieces with this board pattern.
I do already consider the Rotation, and that does makes sense. But on top of that Iād like to constrain the movements or placements of the pieces too.
Because the pieces have board lines before they are nested instead of nesting first and then post processing to make the seams āevenā (or aligned with their longest edge).
could you please attach a Rhino file with a collection of different pieces to be nested (please include their desired board-line orientation) and also a rectangle indicating the total size of your board (please include board-lines also on that)? Iād like to experiment a few ideas
like this, but as hands-on Rhino file that you were actually going to cut for real:
Iāll try to put down a definition, in the meanwhile this is a sort of basic explanation of my idea, in such a way you can stop me now if you think itās basically wrong
the main point is: when we let OpenNest place this blue piece on the board, just that one piece, what is the maximum āerrorā (in terms of board misalign) that I can get?
I think the answer is āalways less than 5.5 units along Yā
this means that we can always move a piece by less than 5.5 units along Y and find its right placement on the board
ok ā so why not nesting pieces that are all enlonged by 5.5 units along Y, in such a way we are not nesting just them, but we are nesting the area in which a solution to their placement will exist?
for instance, instead of nesting the left ones in this picture, we nest the right ones:
at this point we will have another portion of code that just puts the right shape into the right container, and that just moves along Y each piece to its corresponding closest horizontal line
Thinking outside the box is always good. Remember too that OpenNest has a āSpacingā parameter, though it applies to all sides, X and Y.
Iām still hung up on the issue of the input geometry having āboard seamsā instead of finding a best fit in the post processing stage. (even seams top and bottom unless top or bottom is a straight line?)
Hah! I got what I wanted, though maybe itās not what you needā¦ Best explained by looking closely at one sheet. The white curves were done by OpenNest. The black line is the longest segment produced by Convex Hull(the curves are polylines with short segments). The blue curves are done by moving the white curves the direction and distance from the black lines to the nearest sheet seam.
It might not always be the best strategy? In some cases, the opposite curved edge of the parts leaves a vey thin overlap with a seam, which probably should be avoided? But itās very close to what Iāve been advocating, which is to forget about seams in the original geometry and handle that by post processing after OpenNest does its best.
It would be nice if the test data included these parts:
I would modify my green group that gets the longest edge to make sure it is āhorizontalā (parallel with the sheet seams). That would handle the pieces in this image that have such an edge already, and in those cases the long segment from Convex Hull would not be parallel to the seams so it would be ignored. With this small change, these ācorner piecesā that have two square edges would be handled properly.
That leaves the issue of nudging the post-processed curves in Y to avoid small slivers, however that is defined. My Rhino file āUnitsā are inches which makes the sheets 55 inches by 120 inches (10 feet), and the boards 5.5 inches between seams, is that correct? What is the minimum āsliverā dimension in the Y direction? Say 1.5 inches?
this is a very dirty prototype of what I meant
gin tonics have had a bad influence on my ability to do things the smart way tonight, so I solved several small problems the weirdest possible way without thinking too muchā¦ it should be improved in its execution, but the basic idea is there (tomorrow Iāll add some comments to the GH file to give it more sense)
Very nice work. Only ten sheets used! āIterationsā = 1? āSpacingā = 1.
When I use those settings in my model, I get only 7 sheets but a few of the post-processed curves overlap slightly and one exceeds the sheet boundary.
With āSpacingā = 2, eight sheets are used with no overlaps but several parts extend beyond the sheet boundaries! OOPS! I didnāt check for that.
āSpacingā = 3.75 looks OK in my model with 11 sheets required, but a couple of them still overlap the sheet boundary. I can fix that and add collision/boundary detection but OpenNest spacing is my only recourse, which affects X and Y instead of only Y, as yours does. Well done!
P.S. I made a few simple changes and got better results.
Added a āPad Y (scale Y)ā group at the top that uses the Scale NU in Y only to get more room without infringing on X. Transform replaces scaled part with original before post-processing.
Added āCollisionsā at the bottom right to detect (but not avoid) overlaps, including sheet boundaries.
Would you mind sharing the result from this? Iām curious! I also get around 10 sheets in my computer. even with more Iterations and āSpacing = 1ā !
Do you think there is a difference in results based on the pc configuration?
Yes correct with the sizes! sorry I didnāt understand what you mean by āsilverā
Thank you! very much like the idea to modify the input geometry to consider for the seams! that sounds like a good plan.
I will test this further with a larger dataset and compare with what I had previously. Hope this can improve it.
Meanwhile I also made a little benchmark with a manual nesting with these parts.
Those results were using version Nesting_issue_2022Oct20b.ghfrom this post, with changes to the parameter values as noted. But the overlaps (collisions) were unacceptable so I would ignore that.
No.
Version Nesting_issue_2022Oct20c.gh looks much better to me, using ten sheets. Space between the post-processed parts depends on āPad_Yā and āSpacingā values. I havenāt tried yet to avoid the few cases where there is a very small piece on one edge due to board/sheet seam alignment.
P.S. Your benchmark results are interesting, though small changes to parameter values may change them without modifying any code. But again, Iād be interested in trying an expanded set of input geometry including those in the image you shared.
However, they donāt look correct because those parts have not been post-processed. I disabled the āBakeā feature in my last model (version Oct20c) because itās not correctly wired to the post-processed results, which is also the case for version Oct20b. An oversight.
P.S. This image shows sheets 3 and 4 using version Oct20c. These āsliversā are so small that I wonder if the parts are designed to fit in five board widths? 27.5 inches?
