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:
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?
- Solution exception:âNoneTypeâ object has no attribute âGetUserStringâ
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)
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)
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:
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:
- Material: 18MDF, 25MDF, etc.
- 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.
Both of them if possible
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.
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:
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.
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.