Hey @Petras_Vestartas,
thanks for the Update! I’ve played around a bit and looked at the example files, but as far as I can see it still doesn’t work with trees. To achieve the thing you showed in the examples ( you still have to use a separate sheets+geo component for everything that would have been one branch in the old (and more concise) version. This might work for just two branches, but as soon as the number of branches varies each time or is in the dozens, this becomes unusable.
What do you mean by that? Provide a practical example.
Interface for doing that is already here, you can already see from the two components. Now it is just the matter of adding more components.
The reason you are writing this is that Grasshopper and Rhino input components flattens everything to detect holes and group everything together. But outputs one class instance.
Solution: The only user interface I can think of, is to provide user input for sheets and polygons as polylines. This is straight forward to do.
Warning But then it is up to you for simplification to polylines, nesting speed, correctness of the input, copies and so on. I can do that if it has any practical use…
here 100 random different shapes are generated, each of them populated with 1-to-3 holes, plugged as data tree as Geometry
then each of the above is nested in 2-to-4 random Copies into 3 different and weirdly-shaped sheets, two of which even have holes, also input as data tree of Curves
here is the file: OpenNest_datatrees.gh (32.3 KB)
the thing you probably refer to, in the example file “opennest2_1_run_solve_n_times.gh”, shows specifically how two different “jobs” each one with its own shape and its own sheet could coexist on the very same GH canvas and be nested with a single Core-component, but that is just one of the many ways you can do that
if you want -for instance- to nest the very same job into different type/shape of sheets, you can just merge several Sheets together:
OpenNest_datatrees_multiple_sheet_job.gh (32.4 KB)
but the main thing, and this is truly awesome, is the Nest Sheet component → Polylines input does support data-trees -which is awesome- (in that case I guess you should set both Rows and Copies to 1, and take care that you are fully responsible of providing as many sheet-curves as needed to complete the nesting)
OpenNest_datatrees_sheet_monster.gh (30.5 KB)
if for instance sheets are not big enough / many enough to allow for all the geometries to be nested, you’ll see leftovers here:
@inno Thank you very much for helping with this OpenNest thread
you have done an awesome job with the V2
I’m just discovering things while digging into it more and more in the last weeks, and I’m happy to help other people understand, experiment and enjoy the new release as much as I do
Now it is just the matter of adding more components.
yeah, I get that, but adding a new component (or 2) for every branch in your tree is not the way grasshopper is supposed to work and really inflexible.
It’s impossible to input multiple nesting processes as a tree. This means that for example, if I wanted to nest all the small circles inside the big circle and all the small triangles inside the big triangle, I would need two separate sheet components and two geo components, one for each of them. This may be acceptable for just two processes, but is unusable for larger or changing numbers of nesting processes.
What I mean, by adding new components, developing new components. Since now the library allows to do that…
Hi! I am struggling to have a way to identify the curve I’m nesting. I’m trying to keep track of which curve is which.
I would like to have a way to use the layer name the curves were originally on to identify them after the nest operation. I tried with the grasshopper modules with no success (I’m a beginner in grasshopper). I was about to try the python scrip module, but is their a way to do it with the opennest2 module?
Here is my current files.
NestingBC_GPT.gh (22.2 KB)
Untitled.3dm (1.2 MB)
here is an example of reading the Layer-name on which referenced Rhino geometries are, and baking them after nesting on a Layer that has same name with the addition of “_NESTED”
Geometries get imported by Layer, then A “separates” the real Curves from their attributes, B reads the Layer on which each curve lies, C creates a new Layer name by adding the “_NESTED” thing, D puts back geometries (nested curves) and attributes together, and finally E bakes the content into Rhino
NestingBC_NO_GPT_for_gods_sake.gh (24.1 KB)
the reason for adding “_NESTED” is just to give you a destination place where they are landing, while mantaining some sort of reference to what is what… of course you could put everything on their original Layer, or even putting them all into a new Layer and just Name each geometry with its original Layer name… infinite possibilities
just a note, if you are wondering “but how do I know what is what”, the answer is simple: just connect two Area components and check the input and nested areas to check (it stays the same ) so what you have at index i as input you’ll get at branch i as output
brief video on what is supposed to happen:
Wow, thanks for that! I think I succeeded in doing it with Python 3, but the way you did it is how I’ve been trying to do it for longer than I want to admit Im going to try it. Thanks for the tip to!
Hello petras ,
thanks for the great plugin .
rotation is not working in nesting results .
could you please let me know what did i mess .
attached the GH file .
Nesting02_querstion.gh (18.8 KB)
Sheets: 1
Setup: 0ms
Max Iterations: 1
System.DllNotFoundException: Unable to load DLL ‘minkowski’: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
at Minkowski.MinkowskiWrapper.setData(Int32 cntA, Double pntsA, Int32 holesCnt, Int32 holesSizes, Double holesPoints, Int32 cntB, Double pntsB)
at nest_lib.Background.Process2(NFP A, NFP B, Int32 type)
at nest_lib.Background.getOuterNfp(NFP A, NFP B, Int32 type, Boolean inside)
at nest_lib.Background.getInnerNfp(NFP A, NFP B, Int32 type, SvgNestConfig config)
at nest_lib.Background.placeParts(NFP sheets, NFP parts, SvgNestConfig config, Int32 nestindex)
at nest_lib.Background.sync()
at nest_lib.Background.thenDeepNest(NfpPair processed, List1 parts) at nest_lib.Background.BackgroundStart(DataInfo data) at nest_lib.SvgNest.launchWorkers(NestItem[] parts) at nest_lib.NestingContext.NestIterate(Int32 max_iterations) at nest_lib.rhino_example.run(Int32 max_iterations, Int64 max_time_in_seconds) at nest_lib.rhino_example..ctor(nest_sheets& nest_sheets, nest_geo& geometry, List
1 parameters, Int32 max_iterations)
at opennest_2.component_nest.SolveInstance(IGH_DataAccess DA)
I got the error above in my Rhino Command line when trying to run opennest 2 this morning. Other information includes the windows also updated, and my ngon plugin is also acting very strangely and i had to replace all the instances of ngon components in my script.
Also, using opennest 2 in Rhino (without grasshopper) worked fine…
What is your operating system, rhino version and OpenNest versions?
I got that exact error when COFF was enabled
type in Rhino GrasshopperDeveloperSettings
and make sure the check is not present:
if the check is present, remove it, press ok, close Rhino and reopen it (make sure you don’t have multiple Rhino instances open at the same time on the same machine when you do that: just one)
Thanks all for your replies. Tried with COFF disabled, and this worked. Operating system is Windows 11, OS Build 22631.4751, and Rhino Version 8 SR16
(8.16.25028.13001, 2025-01-28), Opennest 2.3.0, after i deprecated from 2.4.0
Will try and update to 2.4.0 again and see if that is alright
dear petras,
first of all: thank you very much for your great work! it did help me quite a lot for getting a proper workflow for calculation and fabrication of my carpentry and interior projects.
but unfortunately after changing to rhino 8 and opennest 2 i got into trouble with my gh-workflows. i tried to adapt my scripts to the behaviour of opennnest 2.4 but up to now i was not able to get the desired output as before. here in detail:
my gh-workflow in rhino 7/opennest 1.5 does the following:
- get all selected geometry (3d-geo, unsually plates)
- sort by layer and thickness
- check if the material (layer) and thickness are in my database
- get sheet size for used layer/thickness combinations from database and create sheets for nesting
- label sheets and parts with rectangular hull size and part-name for manual cutting
- feed the geometry and sheets to opennest in a sorted way
- transform labels to new position
- count needed sheets
expected output
- nested parts, sorted by material and part-thickness and placed on the correctly sized sheets for the corresponding materials
- output of necessary sheet-number for each used material
- labelling of sheet-material and size and part-size and -name
what does work in opennest 2.4
- placement of text-labels and 3d-geometry according to nested outline-curves (when i graft input of outline-curves to opennest)
problems in opennest 2.4
- i can not get opennest aware of the different sheet-“qualities” anymore. all sheets are treated as of the same material and parts are scattered around them in an arbitrary way (compare part-thickness and sheet-thickness on screenshot). i tried to feed sheets and curves (outline of geo) with the same data-structure, but it does not help.
- automatic creation of additional sheets, if they are necessary
most probably i am simply not aware of the correct data-struture that is needed to achieve the old behaviour. i did also check your examples, but i did not find any hint on how this should be set up. fortunately opennest 1.5.1 is working in rhino 8 up to now and i can use my old files still…
here are the relevant gh-files, one testfile with geometry and appropriate layerstructure and some screenshots to show the problem.
thanks,
chris
FraPa_nesting_testfile.3dm (7.9 MB)
nesting_3D_sort_layout_cl_20250212_on1_51.gh (61.1 KB)
nesting_3D_sort_layout_cl_20250212_on2_new.gh (72.0 KB)