Hi all,
I’ve put together a small Grasshopper component that connects the Sparrow nesting engine to
Grasshopper.
It runs on a background thread and is non-blocking.
GitHub: GitHub - coroush/sparrow-grasshopper: nesting for 2D irregular packing in Grasshopper3d · GitHub
Still early - if something breaks or behaves oddly, let me know here or open an issue on GitHub.
update: now available to install via PackageManager in Rhino & Food4Rhino.
are you planning to release it in PackageManager?
yes i would! I like to test it for a couple of weeks more before publishing - if you might have any feedback or ran into issues please share 
woooah gave it a try it looks insanely good! 
I didn’t have any drawing at hands to put it really under a serious stress, so I just used one from a thread I found here in the forum, and I’m really impressed!
there are a couple of things I would mention, but those are not bug/problems, just maybe quality of life things, or maybe just my personal preferences
for instance, the Transform X output, I’d personally like it to have it with same data structure of the C curve input (it now has structure of the IDs output, used the circled thing to make it work the way I wanted)
I tried different nesting times, sometimes there’s a piece that is left in the middle of the last sheet:
but the packing quality looks really awesome in my opinion
by doing several tries with different time limits there’s one thing that I really hope could be implemented 
let’s say that I nest for 10 seconds then I think “I wanto to give it 20 more seconds”, if the time limit is the only input that made the components expire, I hope there will be a way to just continue the previous computation without having to re-calculate the initial 10 seconds?
the only other thing is, is there any way to select a seed, in such a way result on same pc and same seed might be repeatable?
Not working on my system, Windows11 and Rhinoceros v7.38.24338.17001 because your plugin it is compiled using the SDK v7.38.24338.17002. Where I can find a newer version than v7.38.24338.17001?
P.S. Just checked the Rhino - Download - Rhino SDK 7 for Windows and looks like the latest version of the SDK available for download is v7.38.24338.17001. Where I can download the v7.38.24338.17002?
maybe that is a Service Release Candidate?
No, it is the same SR but with an additional number at the end: v7.38.24338.17002 vs v7.38.24338.17001.
Thank you @inno ! so a couple of questions:
- about the transform, im thinking that benefit of this way is that nested curves have the same data structure with transforms (and any attachments that we bring later) which is based on sheets. is there another point that im missing?
- for continuation, how would you imagine the workflow? do we have another input that says continue or start fresh? or does this mean to take an initial arrangement and optimize from there with another chained component? i will have a look what it takes to do this
- about the seed! so yes the seed is actually an option that i place randomly now. because the solver is working with time; it could do different iterations on different computers or even on the same computer (depending on other processes running too). so I thought its misleading to use seed and assume deterministic results. I could also add iterations and we say do 100 iterations with this seed. but I feel maybe two termination criteria could be confusing? any suggestions what would be the good flow?
thx! i updated them here
Thanks for the tool, I am testing it now on this use case
I will have to compare to OpenNest and the other paid tool.
I think I will have to make a tool to nest inside holes. If you implement holes it will become a quite complete tool. It will surely require to have curves in DataTree.
It seems promising but I has lots of timeout (surely no good nest on requested time).
A bit frustrating after 1000 s (inter bin moves),
The Id and Transform is OK for me as it looks like what I did on some Packing tool in Nautilus. User just have to group curves or others object to apply the transform.
In my use case I also have different sheet size. My laser cutter can’t use 2000 mm x 1000 mm sheets so I use 600 mm x 600 mm and 400 mm x 600 mm.
Thank you. Working now.
Thanks for testing! that’s indeed strange! as far as i tested it usually returns a decent result after 30 seconds (around 500 objects). could you share with me your input data? i wonder if there is an error happening thats not reported correctly.
Thanks i ll send you the script and data once I am back at home
Looks great! Nice job. I thought about good open nest alternatives for a long time. I know its a wrapper, but i thought it would be nice to try to run sparrow on gpu, testing multiple rotations at the same time.
I agree with you on that, the only thing is that the nested curve have already got that Transformation applied, so I personally don’t find it particularly useful
in the case I presented earlier I was nesting some outlines that contain many other curves: the outline is used for nesting, and then the transform data is applied to those contained curves in order to make them follow the nesting transformations of the their outlines
because of that, you need some sort of data tree handling anyways, like mine or like the more direct one that Laurent used:
Sparrow_Nest_is_awesome_2.gh (285.0 KB)
meaning that every time you want to actually apply the Transformations offered by the SparrowNest component to some curves which are not the ones you actually nested, you always need to recall those by the ID output first, which is like 2+ more components that you are always going to use, but most important (to me) this is changing the data structure from whatever you had before, into a per-nesting-sheet base, which might be something you don’t always want (but of course there could be times this option is preferred)
if the Transform output had same data structure of the Curve input, instead, you would just graft it and Transform the data tree of contained curves directly: the data structure of your curves does not change because of the Nesting
to be fair, I see the reasons why both Transforms options could be very useful… 
sorry for double posting, I saw my previous post already got some reactions so I didn’t feel like editing that with new text
I’m like at 0% knowledge on how to build/code GH components, but I read some threads here and there in this forum, so I heard about some “macro-topics” like principle of how it works, but I have no idea of the details
I’m wondering if it’s possible, for an expired component, to know which input or inputS changed before/after its expiration
if all:
then → continue calculating from the point you were before expiration
which is a terrible way to say, if at a certain point I’m not happy of my 1 minutes nesting and I want to try 2 minutes, maybe I don’t have to re-calculate also the first minute again, as the result of the first minute is already in front of my eyes while I move the mouse on the slider to increase the time
[again, my assumption can easily be completely wrong, so take it as if it was coming from a 4 year old boy ]
lastly, about the seed, I understand what you mean
I think reasoning in terms of iterations+seed would be easier, instead of time (which of course is also hardware dependant)
I think that mostly would be useful for troubleshooting, for instance if I wanted to let you know what specific settings led to the creation of those shapes in the middle of the rightmost nesting sheet earlier (another thing that comes to my mind, GH class where each student is trying to redo what the teacher does on screen, but each gets a different result)
I don’t think repeatability has absolute and unquestionable value, but for sure would be a very welcome addition (eventually with dedicated inputs that can be exposed only if the small + is clicked after zooming-in a lot, like the new R8 components)
[edit] maybe things could be like they are now, but there could be another output of some sort with some debugging text? in such a way to tell you “this solution was generated with random seed 1234567890 and 97 iterations”
so you are able to use those data to reinstate it and see what happened under the hood? [/edit]
by the way, a lot of words from my fingers, but be sure that it’s already fucking awesome as it is now 
I do get quite bad results by nesting the “Sparrow_Nest_is_awesome_2.gh“ definition.
This is what I do get by default, without changing anything. Note the small shapes that are wrongly nested?
It is possible to add SURFACE or BREP nesting support? This way the more complicated shapes with holes should be nested correctly.
I see a lot of shapes are missing, this looks like a problem that comes before the SparrowNest component, most probably is already present in the data tree due to maybe R7 differences?
The first thing that comes to my mind is to check the Curve Offset direction at the very beginning of the definition, and also the Region Union result, it should be something like this, which is a sort of outer contours of the bigger parts, even the ones that are separated, in order to be nested together:
This solved the issue (for now):
It uses the SurfaceBorder component from Sasquatch.
Sparrow_Nest_is_awesome_3.gh (271.5 KB)
Has managed somebody to nest 3D parts? I am thinking to a mixed workflow, create the 2D silhouette of the parts, nest the 2D shape, use the transformation resulted to move the original 3D shapes on the nested sheets. The only issue, I get mixed results.
