OpenNest can't use some shapes

Unfortunately Elefront it is not very reliable (using the one with 6-es on icons). I tryied to use some components to read the Keys/values of the objects and messed-up the entire definition. I can provide an example file if somebody interested to do some debugging and head scratching.

I’d like to see a Rhino file with some examples of holed surfaces that contain quantity attributes? Not very interested in messed up code though…

this reads/filters user key/value pairs in Python


Py_KeyValue.gh (8.4 KB)

it will output Null for objects that do not have the chosen filtering key assigned:

1 Like

So simple! I love it. But you didn’t internalize your curves. Is there a Rhino file I’m missing?

P.S. I created a Rhino file with four rectangles and assigned ‘key_1’ values to each but can’t read them?

  1. Solution exception:‘NoneType’ object has no attribute ‘GetUserString’

1 Like

I did some experiments and deleted scriptcontext lines in the Python component that I shouldn’t have deleted…

here is the good one (it works in R7, should work also in R6 ?)

Py_KeyValue_Re.gh (9.2 KB)
test_curves_R6.3dm (25.4 KB)

1 Like

Much better! Nice work.

import Rhino
import rhinoscriptsyntax as rs
import scriptcontext as sc

sc.doc = Rhino.RhinoDoc.ActiveDoc
a = rs.GetUserText(curve, key)

I used @inno’s Python script to greatly simplify my version ‘b’ code from yesterday. I deleted the code that isolates unique parts on the assumption that all surfaces in the “unique parts for nesting” will be unique. Surfaces may have holes. I deleted @Petras_Vestartas’s SortGuids because using ‘Guids’ confused me and I couldn’t get it to work… I replaced it with the white group (“ignore holes”). I replaced the ‘Gene Pool’ set of sliders with quantities from @inno’s Python script, which are attributes of the surfaces. I used only one ‘Sheet’ (internalized) because I don’t understand how OpenNest works with multiple sheets when there aren’t enough sheets for all the parts?

To me, this is simple, obvious and elegant.

UPDATE: Replacing version ‘a’ with version ‘b’ - Playing around a little bit, I modified the quantity for one of the surfaces (the big one) and noticed two things:

  • The list of quantities from the Python script doesn’t change unless you reconnect its first input (which I renamed from ‘curve’ to ‘geo’ because these are now expected to be breps (surfaces with optional holes) instead of curves.)

  • I might have been confused but it appeared that the Repeat component didn’t respond correctly to this change, so I grafted its inputs to fix that.

I reduced ‘Iterations’ from 100 to 50 which is much faster and seems to work well enough.


Nesting_issue_2022Oct1b.3dm (66.2 KB)
Nesting_issue_2022Oct1b.gh (20.6 KB)

1 Like

I do found this definition that can read the Keys/Values from any kind of geometry:

We’re beyond that now, though @inno’s code is very similar. See above for how to use an attribute as quantity for Open Nest.

I do found something interesting:

RhinoCNC for CNCStep

I need to look into this as maybe I will be able to skip the part with export/import DXF files into Maestro to generate the Gcode files and I will be able to do this part also in Rhino/Grasshopper.

As I see, a lot of you guys are able to write Python scripts.

I am thinking that maybe somebody will want to continue the development of the EasyCut plugin, as seems that the initial developer abandoned this project two years ago, and the source code of the Python script it is available in GitHub

I am interested if possible to modify this script to add two more field:

  1. Material: 18MDF, 25MDF, etc.
  2. Mechanisation: (CNC, BeamSaw, Spindle)

and remove the “Layer” field.

Also a very useful feature will be to be able to select multiple cells in a column and type only once and fill all the selected cells with the same information. It is quite time consuming to copy paste into every cell because right now you can sellect only one object at a time.

Sounds like you are more interested in long term dreaming than immediate solutions.

1 Like

Both of them if possible :slight_smile:

Hi,
I haven’t heard of anyone else having issues with these components, and the R6 version has been stable for quite some years now, so this sounds unusual. I’d be interested to see the example file, if you still have it to hand.

Now it is working again, but for some odd reason was a time when using the “Define User Atributes” and “Bake Dots” just flashed the dots on the screen and they disapeared, so I used some aditional components like “Tag” to be able to do my job. Not even pressing the “Activate” button on “Bake Dots” did’t worked.

Elefront_bug.gh (119.4 KB)

I simply asked if there is any code taken from SVGnest used in OpenNest.
Is there?
and is the source for OpenNest online somewhere?

I believe this is the first time you’ve ever acknowledged any connection between SVGNest and OpenNest.
Perhaps you’re mixing it up with previous discussions about you properly crediting your use of Ryan Schmidt’s remesher, or of Gianpaolo Savio’s code for mesh curvature, or of the Polylabel library.

That is an incorrect characterisation of Kangaroo, and frankly seems like an attempt at deflection - it’s a separate topic not relevant here. I will correct it once here for the record, but if you want to discuss Kangaroo further, make a different thread.

Kangaroo pre-dates the entire Shape-Up/Op work by several years. They invited and hosted me multiple times in Lausanne to present and discuss Kangaroo before those projects, and the influence goes both ways.
One part of the improvement in the K2 solver involves an idea about projections which came from in person verbal discussions with LGG before and during the development of ShapeUp/Op, but applied independently and in a rather different way. Kangaroo is not a rewrite of anyone else’s work.
There is not and has never been a single line or character of code ever taken from them used in any version of Kangaroo.

1 Like

The explanation of Kangaroo2, I already know that is the reason to mention.

K2 in one conference, was mentioned like this:
“We developed “ShapeOp” that is more known in architecture community as Kangaroo2.”

I am thankful for spending your free time on Friday evenings while dropping single line comments…
I went through tons of nesting applications and codes in .NET and C++ before publishing this app.
And still I have been spending quite a lot of time on the development for nesting. So these kind of comments completely demotivates to push forward any kind of open source tool on McNeel platform.

This was the first post where I managed to compute minkowski boolean unions long time ago by using only clipper library by angus johnson: Minkowski distance - #10 by PeterFotiadis

We do appreciate your work on nesting. I know it has been useful to many in the community here.
I was asking about where the code comes from, because your plugin doesn’t seem to actually be open source. I recalled mentioning svgnest in that same discussion with you many years ago, so I just wondered when seeing this discussion the other day about the connection, if any, and a search here for those terms showed that opennest error messages do include some references to svgnest and deepnest files (Tutorial for OpenNest - #2 by diff-arch).

Whether it was written from scratch or if it is a mix of original work and bits of other people’s code, or a rewrite and modification, or even if it had been a direct port, that’s all good as long as the licenses allow it, I just personally think it’s also good practise to always properly acknowledge the contributions of the original authors whenever using their code.

For a permissive license like MIT, there isn’t a requirement to also make the new work open-source, but I believe you are still legally required to include in the distribution the original author’s copyright and license statement somewhere end users can see it if you use ‘substantial portions’.

I’m sure many users don’t care about where all the code comes from or how it is credited if it does what they want, but I think it can actually help foster a respectful environment, encourage other developers and push the development forward to be clear about it, and doing so for any portions which are borrowed doesn’t devalue all the other original work that goes into it at all.

And for these errors at the end of your reference post, you posted, you can see that there is a new code.

You can speak about licenses but OpenNest went into a different route of development which is when I learnt the logic instead of only solving dependency problems:
StraightSectionA0

My own code was reused multiple times and without even noticing me. I shared how to run it in private messages both in python or C#.

So I strongly dissagree with your message here because it implies something. Unless we will start citing the papers and math of people who originally targeted those problems. Which is much more difficult than implementing them in different programming languages. And those people must be cited in the first place.

Thank you for sharing your opinion.

1 Like

I don’t know how you got that GIF but we’ve seen recent examples where OpenNest is nowhere near that good (or fast) at packing shapes:

From a usability POV, I don’t want to bother with decisions about rotations, iterations or seed. I just want it to work well. Also, the convoluted handling of shapes with holes in them is a pain.

1 Like