Open Nest - occasional pieces not nesting

When the developers of RhinoNest decided to abandon their software I shifted over to OpenNest.
Many thanks to Petras and the team at OpenNest - it is a truly wonderful tool.

99% of the time it works perfectly, however every now and then I get an internal piece that simply will not nest. I can’t for the life of me work out what I need to fix.

Attached is a simple single piece consisting of an enclosing polyline, a text object and a mesh. I’ve also attached the GH definition I’m using (stripped back to bare bones to keep things simple).

The container polyline and the text object nest fine, but the mesh does not.

Could some of the bigger brains than mine please tell me what I am doing wrong.

Many thanks, Steve
opennest-2619023.3dm (350.2 KB)
3Dinflate-nesting_101023.gh (16.9 KB)

I think the RhinoObjects is filtering something upstream, which does not reach the baking component:

may I ask how is your definition before the guid parameter? because I guess some small changes there might make things work, it’s just a matter of organizing a nice data tree

Thanks Inno,

All text I have nested has behaved fine in the past and it is nesting in this case also. The missing item in the data tree is the mesh and I can’t work out what is causing this. The mesh reports as valid under Rhino check.

Regards, S

what I mean is that the mesh is filtered by this component:

the mesh guid gets in, but never gets passed to the baking component on the right

if you connect the whole original guids to the baking component, then also your mesh will be baked:

of course this works now because you are nesting a single object, but this won’t work if you have multiple: for this reason I would maybe suggest a slightly different strategy on the part of definition that is upstream, and you did not include in the gh file :slight_smile:

Thanks Inno,

Yes that’s the problem, the mesh gets rejected by the RhinoObjects component.
What I’m trying to work out is what is wrong with that mesh that causes it to be discarded.

Attached is another file. I have added another piece that is from the same job. The piece on the left nests fine, but the one on the right drops the mesh.
As far as I can tell there is no obvious difference between the two, but for some reason the right hand mesh is not loved.
Can anyone see an obvious problem?
Thanks, Steve
opennest-2719023.3dm (368.3 KB)

I convinced myself the culprit was the mesh :slight_smile: so I started checking things around:

the mesh, visually, has 18 rows of 4 faces minus one on the top left corner: 18*4-1= 71 faces
but gh recognizes 86 faces on that?

so I did a face normal, and indeed there are more faces than expected: here the center of each face is traced

something odd is going on :slight_smile:

how was that mesh generated in first place?

Hi Inno,

Thanks so much for taking that effort. I was doing the same investigation as you and discovered the same extremely strange mesh formation. That mesh was generated useing Squish which does some odd things occasionally.
I’ll try some different settings and see what I come up with.
At least we know what we are dealing with now. Many thanks for your great help.
Steve

1 Like

This mesh contains 5 n-gons. This is the reason for the discrepancy between the number of faces you can see and what is reported in grasshopper or with the _What command in Rhino.

You can use the _RebuildMesh command in Rhino or eliminate the n-gons and see the actual faces.

After experimenting with some test meshes, I believe that these meshes that do not pass though the RhinoObjects component have a bounding box center that is more than the Tolerance (T) input value outside the “bounding curve” (the curve on the “ernie split::CutContour” layer of your file).

In the first test case, the bounding box center and area centroid are both within the “bounding curve”. The mesh’s guid is passed through the RhinoObjects component.

In the second test case, the bounding box center is outside the “bounding curve” but the area centroid is within “bounding curve”. The mesh’s guid is not passed through the RhinoObjects component.

In the third test case, the bounding box center is outside the “bounding curve” and the area centroid also outside the “bounding curve”. The mesh’s guid is not passed through the RhinoObjects component.

Adjusting the Tolerance (T) input to the RhinoObjects component to a value greater than the distance to the bounding box center will allow the mesh guid to pass through the RhinoObjects component.

Here’s the files used for the testing above.

tests.3dm (2.5 MB)
tests.gh (20.8 KB)

In the cases where you’re trying to nest these meshes with concave shapes, you could just increase the Tolerance (T) input to the RhinoObjects component. You might also have to increase the spacing of your source geometry to accommodate this.

Another possible solution would be to extract the edges of your meshes and just nest them instead.

-Kevin

1 Like

Well that was some excellent detective work Kevin.
Many thanks, you have solved the problem for every instance that I have encountered.

Best Regards, Steve

1 Like