OpenNest for Rhino8 - plugin update

I tried. It’s a lot of work to document the steps I took and what happened… :roll_eyes:

Like most people, I haven’t read the examples you referred to or much about OpenNest in R8.

In R8, I opened the file OpenNest2_2024_Jul10cR8.gh that I had posted four days ago:

I started PackageManager and saw that OpenNest was already installed but I tried to install it anyway, thinking it would update. That apparently didn’t work, so you must uninstall the old version first? So I did that, restarted Rhino and tried PackageManager again, which seemed to work this time, though at some point (twice) I saw the following message:

I saw the OpenNest components I had installed four days ago but nest_geo was red with this error message:

  1. Solution exception:Input parameter index [4] too high for Component nest_geo.

nest was orange with this error message:

  1. Input parameter nest_geo failed to collect data

So I grabbed new copies of both from the ‘OpenNest2’ toolbar, with no indication that I was now using 2.1. Instead of the Rectangle I had used for the ‘nest_sheets’ input (old R7 style), I grabbed a nest_sheets component and connected all the new ones together. At a glance, it works :bangbang:


OpenNest2_2024_Jul14aR8.gh (777.7 KB)

However… There are more parts than will fit on the 4 x 4 grid (‘array_x’ = 4 and ‘array_y’ = 4) with no obvious indication that 16 sheets isn’t enough. Unlike R7, it apparently doesn’t add sheets automatically? I’m not sure what’s going on with parts outside of the sheets grid? Is that the que of parts yet to be placed? ‘array_x’ = 4 and ‘array_y’ = 6 appears to be enough.

So bottom line, yes, it appears to work much better than before. AHA!! Increasing ‘num_of_rotations’ to 4 makes the que go away. Will take some getting used to this.


OpenNest2_2024_Jul14bR8.gh (779.9 KB)

P.S. By the way, is this an R8 quirk? (flaw!) I ignored it when modifying ‘num_of_rotations’ but it bothers me when I try to modify ‘spacing’. In R8, it looks garbled:
OpenNest2_2024_Jul14b2R8

In R7, it keeps lines intact:
OpenNest2_2024_Jul14b2R7

P.P.S. From what I can tell, the garbled text when editing ‘options’ is unique to OpenNest2 and is not common to R8 text panels.

2 Likes

Thank you very much a good feedback.

  • It seems I need to document the new workflow videos.
  • For sheets I ll try to create a linear array of sheets inside component again when only one polyline is added.

Do you think it would make more sense to add individual parameters to nest component rather than the panel? Initially I did not want to create a super big component with params. Maybe I should just internalize parameters and the user coupd change them by right click, instead of using a panel.

The package manager behavior is weird, in my case it installed the newer version. But I see similar cases for multiple users: first remove the previous version, then install again.

Probably yes, especially given the garbled text panel when editing options.

Except for helping people on this forum, I don’t use OpenNest for my own projects so may not be the best person to ask about changes. I have other ideas and questions but am not fully awake yet.

I see ten images there (and a video I haven’t watched yet) but no code examples? That would be very helpful to me. Oh, wait, I see this now: “OpenNest_2_1_0 Rhino 8 Example Files

15 GH files and one Rhino file… OK, will check them out before saying any more.

1 Like

Reactions:

  1. opennest2_1_nest.gh - Useless because the single square curve is already on a sheet.

  2. opennest2_1_nest_attributes.gh - Confusing, how can geometry be “attributes”? And why is Transform crossed out and discouraged, with its wires hidden? Maybe only for attributes?

  3. opennest2_1_nest_rhino_objects.gh - Confusing and useless. This one looks broken as it apparently needs the Rhino file, but opening the Rhino file doesn’t help unless it is opened before the GH file. By the way, this Rhino file has two ‘Top’ views and no ‘Perspective’.

  4. opennest2_1_nest_simplify_explanation.gh = Very confusing :exclamation: I guess the point is to demonstrate the nest_geo ‘simplify’ and ‘copies’ inputs. But passing the value of an unlabeled slider (-500 to +1000) through a text panel is not recommended, especially when the panel isn’t wide enough to display values without wrapping.

In general, having text panels, Boolean toggles and geometry params connected to OpenNest inputs is distracting and doesn’t work for me. Same goes for the groups with verbose titles.

  1. opennest2_1_sheets_with_holes.gh - I don’t see the point of supporting odd shaped sheets with holes, but whatever… It’s confusing to me that the 3 sheets in this example must be grafted when the list of 110 copies of a single square is not grafted?

  2. opennest2_1_timer.gh - I don’t understand this example at all? Looking closer, I see that in the text panel of options, ‘time’ has been modified. Is that a max limit? Default is zero.
    timer

  3. opennest2_2_unroll.gh - This is weird. Why is the second example in this file scaled so small? Better to skip Scale and adjust ‘X’ and ‘Y’ values of Pack. It’s too bad Pack doesn’t figure out spacing automatically (using bounding boxes), perhaps with ‘X’ and ‘Y’ gap values.

This is getting tedious, time for a break, maybe continue later. Eight more examples.

1 Like

Thank you very much for such a constructive feedback :slight_smile:

1 Like

I got to try this update today and the new transform output works! I’m not sure if I fully understand how the new nest_geo with attributes work even after looking at opennest2_1_nest_attributes.gh, so I just did it the old way with Transform, as shown here.

Whenever I tried to connect the rest of the tree to the attributes input, I get an error. Would love to hear from you how to use this feature properly.

I’m also curious if there’s a way to do all of this automatically without using manually grouped curves, Human ObjectAttributes and AssignPaths. For example any internal curve (enclosed or not) could automatically attach to the biggest enclosed curve they are a part of. Of course my use case is limited to 2D nesting so this might not work for other cases.

I didn’t have any problem installing the new version, in fact rhino 8 seem to have updated it for me before any file was loaded.

I noticed this too.

And I think sheets make much more sense now that they directly generate from the width and height input instead of that AND a curve input, and I love that it’s still possible to use scraps of different dimensions.

Well please ignore what I said, after just a bit more careful reading of your example file I understood that as long as curves are closed and put into trees they indeed are recognized as one whole object.

1 Like

For grouping objects into closed and open curves Rhino Guid option already works like that.

Shall I create a custom component for handling this case for Grasshopper Geometry objects?
Honestly this case you are referring to is quite often used.

or

If objects are not closed curves, I will just simply place to attributes.

1 Like

Well what do you know… I just needed to spend time reading the doc!
opennest2_1_nest_rhino_objects.gh already demonstrates this feature and I don’t know what more I could ask of.

So I think you’ve done an amazing job tying all of this together already.
What I will say is… it takes time reading the doc, and it certainly didn’t help that information was scattered and sometimes redundant. If everything was in the same demo file, I think people will start making visual and therefore cognitive connections on how each component worked, and you’ll probably get a lot less stupid questions like I had asked.

Thanks for this great addition to an already amazing plugin! Just think of all the plywood sheets you’ve saved us from putting in landfill. If anyone should get a big bonus for saving the planet its you!

1 Like

:smiley: Thanks. Do you think it is worth to create a GitHub documentation page? Or people will never read docs anyway and your suggestion to place everything into a single file would make the most sense?

I am wondering if a Github page where people could contribute by example files would help.

1 Like

I will gladly read any web doc over demo files, but in practice demo files are much more effective in getting people to do it themselves and learn quicker. I would keep doing what you did with the food4rhino upload, but put that information into package manager too so people know where to look when they have a problem. And yes, a giant mind map documenting workflows in a single file, sounds like the way to go. People will ignore a .zip but when they see doc.gh they will have no excuse to not look at it.

I don’t want to take away from your free time at all but here’s a thought for when you feel like it… I personally know a great lot of people who will try to make their first nest really efficient and they feel good about saving material. But what happens next?

They forget about that last piece and just put it in the dumpster. Because it’s tedious to keep track of what you have and its cheaper (time use wise) to just buy a new sheet.

I’m in no way saying that you should take on the responsibility of their wrong doing. But, if there’s a way to make it “cheaper” to reuse material, people will do it. If you provide an additional output that is formatted to work with opennest effortlessly and makes it easier to keep track of their scrap library digitally, it will take opennest to the next level.

Here’s what I think that might look like, a library file created by the user or the plugin, that keeps track of date, material, thickness, and left over shapes. Used in conjunction with opennest, it reminds you that which sheets from a previous job fits the current criteria and can be used again. If you no longer have that sheet, simply delete it from the library. You bought a new batch of sheet material, well there could be a way to put that in the library too.

Just a very raw idea for what it could be and I apologize for the sidetrack. Please don’t let this post ruin your day, I think you’ve already done more than enough for the benefit of everyone. Let this be just one of the potential routes that opennest can take in the distant future.

2 Likes

More Reactions: (examples 9 through 16)

  1. opennest2_3_pack_boxes.gh - Interesting. PackBox looks quite powerful on its own. Outputs boxes requiring Transform to replace boxes with parts. Puzzled by OpenNest Hull (not the standard GH component with same name) orienting some faces(?) to the origin? Will have to study this further. Differing scales make this a little hard to see.

  2. opennest2_4_pack_line_or_grid.gh - Seems odd that XY plane must be replicated?

  3. opennest2_5_text.gh - No questions, very simple, probably no need for this one.

  4. opennest2_6_concave_polygon_center.gh - Same for this one, though InscribeCircle looks handy. :+1:

  5. opennest2_7_projection.gh - Odd but OK.

  6. opennest2_8_bounding_box_edges.gh - No big deal, this can be done without BBoxEdges.

  7. opennest2_8_region_slits.gh - RSlits might be useful for waffling? Didn’t know there is a standard GH component (same name) that does the same thing. In R7 too.

  8. opennest2_9_principal_component_analysis_oriented_bounding_box.gh - OK, an oriented-bounding-box is cool.

1 Like

I think it is a nice idea!
Geometry could be serialized into e.g. a JSON file. I will think how to do this, but would be could to have!

1 Like

@Joseph_Oster

Thank you very much for the comments and review.
I will implement changes and push it as a new release!

Awesome!

Hi Petras_Vestartas, I have some doubts about using OpenNest2.1, I don’t know if I am using it wrong.

Some surfaces were unrolled and I had to split them up or manually modify them before typesetting, so I often use ID nesting. But when some of the outer contour is more complex, the ID function cannot be entered.

What I did was create a Hull layer, then use the Convex Hull function to generate the outer contour, nested with ID, and then close the Hull layer when the layout is complete. You suggested that we use the attributes function, but it does not output the input layer like the Transform Guid function, so the curve generated by the Hull will also be in the plate. At present, the experience of this attribute function is not very good.

Also, I need to get its outer contour line to input into nest_geo. If I connect brep in RhinoObjects directly to nest, it will fail. What do you think about changing this breps to an outer contour.



Then, the spacing between the pattern and the edge of the board is too close, and the board is not arranged according to the spacing setting. As a result, some patterns will appear outside the board, while the spacing between the pattern and the board in OpenNest1 will be placed according to the spacing setting.

Oh, I forgot to update a nest_rhino_geo, but there is no output on the right side. Am I using it wrong

For nesting rhino objects, yes you need completely different component.

Click on your keyboard insert to bake the result.

Not sure why there is no output. I need to check once I am next to pc. Be aware that OpeNest works by nesting polylines first. Curves should work too, but they go through simplification process. And breps can be nested only as attributes placed inside the outlines.

1 Like

Hi Petras, this is currently a problem for me. Open nest does work on all polylines fine but it fails dramatically on a curve. i don’t know how to fix this:

as you can see, nesting failed. help please ;;