OpenNest2- Troubleshooting Brep conversion and "Object reference" errors

Hi everyone,

I’m a total novice with Grasshopper and I’m trying to use OpenNest to automate nesting for some patches for a plotter. I’ve followed several video tutorials, but I’ve hit a wall with an error I can’t seem to bypass.

I have converted all my input curves into closed polylines.

Everything is strictly on the World XY (Z=0) plane.

I have tried both with and without scribes (including text and exploded curves), but the error persists.

Errors:

  1. 1. Invalid cast: Brep » nest_geo

  2. 2. Solution exception: Object reference not set to an instance of an object.

Any help would be greatly appreciated!

Autonesting.gh (17.3 KB)

Patches to nest.3dm (964.2 KB)

I’m not that expert in using Rhino Guid import tools, but if you are happy to use layers instead, this could work:

Autonesting_inno.gh (45.4 KB)

to make things a bit more automated you could use a Geometry pipeline on the layer names, filtered using Curves and something like *CUT* and *SCRIBES* (sheet is on layer 0) {the most important thing is that layer naming and content is always the same, boundary curves always on the layer CUT, sheet on 0, ecc etc}

Autonesting_inno_pipelines.gh (29.5 KB)

Lifesaver! I definitely need to study more. In the meantime this works like a charm.

Thank you a lot

1 Like

Hi Inno! I tried other geometries and i noticed the curves are now polyline even on the output.

So i tried to use transform geometry to just rotate the initial shape but it’s a bit of a mess.

I ended up including the border in the scribes too so everything get transformed and changing the final layer by hand. is there a smarter solution for this? Thank you!

Patches.3dm (500.8 KB)

Flattening the transform block inputs some of the patches fall in place

Without flattening

Including contours in scribes

yes, you are right, sorry for that, everything becomes polyline if it goes through the OpenNest_Geometry calculator :+1:

if you want to use Transforms, this should work fine:

Autonesting_inno_pipelines_Transforms.gh (24.9 KB)

And the output will be exactly the input geometry, just translated/rotated


the reason why these 2 shapes are not being nested is because rotating them by 180 degress (360 divided by Rotations value, which is 2, so 360/2=180°) does not allow those to be contained in the sheet height, so they are not part of the nesting

increasing Rotations to maybe 3, for sure 4, will eventually allow EVERYTHING to be rotated in steps of 120 degrees or 90 degrees

2 Likes

This is amazing! Thank you! super kind!

Hi! I wonder if I can get some more help with this.

Autonesting_inno_pipelines_Transforms WIP.gh (30.6 KB)

patches.3dm (1.1 MB)

So I keep trying to make this tool as clean and foolproof as I can. I added a layer selector and a baking option. I’m trying to turn it into a cluster leaving out:

  • Dropdown menus to select cut layer, scribes layer, and sheet layer from the ones in Rhino.

  • Nesting options.

  • Selecting whether to output curves or surfaces.

  • Number of iterations (I still didn’t understand if this actually improves the solution; it doesn’t look to change anything with the files I tried).

Once the operator is happy with the preview, they should just hit a single bake button and the result is computed in Rhino and no other previews are shown. I’m facing these problems:

  1. The Jitter/Multiple Iterations: Even when I stop the OpenNest solver, hitting the bake button seems to trigger a re-calculation that results in multiple overlapping objects being baked, sometimes offset by a fixed distance. I tried using a Data Dam or a Data Recorder as a buffer, but it didn’t solve the issue.

  2. Sequencing scribes baking and cut baking: I am trying to use a single “RUN” button to trigger two separate bake operations in a specific order (Scribes then Cuts) without the user having to click twice. If you bake the other way around, OpenNest recalculates things and moves the scribes according to the new nest solution (see pic).

I’m trying to understand if it’s possible to freeze the output geometry once the operator is happy with the result, and bake that instead of recomputing constantly. I tried using data dams and recorders as a buffer, but it still recalculates things even if OpenNest run is set to False.

Thank you again!

if you are using Rhino8 there are many new GH components that would make your life much easier, which Rhino version are you on?

Rhino 8.

At the moment, to prevent multiple plot of geometries i use Data Dams between transform block and bake block but is quite annoying that i have to press play every time i run the solver.

the reason why the OpenNest retriggers is because you have GeometryPipeline that reads the content of a given Layer

when you bake the result of the nesting, you use the very same layer where non-nested geometries came from, so adding items to that layer re-triggers the Geometry pipeline which imports also what you have just nested and baked and nests them again :slight_smile:

I think your setup would work fine as it is, if instead of baking stuff on the very same layers you would just bake on new layers (or existing but not auto-imported layers)

I thought of that but also it was happening when turning the boolean toggle to “false” after running

this combo of Rhino + GH file doesn’t trigger any OpenNest computation on my machine:

Autonesting_inno_pipelines_Transforms WIP_INNO.gh (38.0 KB)
patches_inno.3dm (1.1 MB)

(I added a Curve Join component in order to eventually bake curve boundaries as single closed curves instead of shattered parts, and merged the two bool-buttons into one in such a way it just bakes everything at once)