I’ve noticed on macOS in the Rhino 8 (8.31.26126.13432, 2026-05-06) that the Options buttons seem out of alignment comparing to your component screenshot above:
I wonder, is there any way to still set options externally to the component? My defs needs to be used by other people and sliders are only at the beginning of the def.
Also, it was nice to have a boolean gh button to trigger the calculation.
It’s true that options are not changed that often. I would say that boolean alone would be enough!
I was also using spacing/gap semi-often, which was the same slider connected to sheet offset, because there is not way to set an offset from sheet borders.
What do you think about allowing different rotation constraints for some objects within a single nesting process?
In many cases, freeform objects can benefit from 360 rotations to achieve the most efficient packing, while “rectangular objects” often need to be limited to only a few orientations, such as 4 rotation steps. Currently, this can require separate nesting operations, even when all parts belong on the same sheet. It could be useful to assign different rotation settings to different groups of geometry so that all parts can be nested together while respecting their individual orientation requirements.
Perhaps this could be achieved through Grasshopper branches, where one branch could use custom rotations and another branch could use 4 rotations within the same nesting operation.
On API level this is already here, but not on Grasshopper user interface.
Yes it would result in faster packing, correctness when aligned to a direction and potentially tighter packing.
Since elements to nest have their own component, it can be a parameter of them.
why do you canceled the opennest options as single component? We taked place opennest in clusters and have inputs like rotation and seeds outside. now our definitons don’t work! we must rebuild the workflow new - in a running system for our clients. That is not amuseable. please think about this. Tobias
There is always a fixed previous version, that what is the version control used for. So your code and your client code would always work.
Since I don’t have any clients using OpenNest, I’m not familiar with the actual use cases. I am not getting paid for this, except having fun in development.
I’ll consider bringing the Options back into the OpenNest2 component, as they were before.
That said, please keep in mind that the library is continuously evolving. New options are introduced, the solver has been upgraded because the previous version did not perform reliably, and some optimizations were getting trapped in local optima. I’m also constantly discovering new ways to improve the nesting process and achieve better results. Let alone, it was rewritten in a completely different language.
For these reasons, maintaining full backward compatibility can sometimes be challenging.
I wanted to raise a constructive point regarding the use of custom “on-component” UI controls in Grasshopper components, as it can inadvertently introduce friction for certain workflows.
There is a growing segment of the community using non-canvas user interfaces—such as HumanUI, Synapse, or DKUI—and some who even compile .gh files into headless Yak-deliverable Rhino plugins. In these scenarios, the end-user has zero access to the actual Grasshopper canvas.
When standard input parameters are replaced entirely by custom capsule controls, it removes any possibility of remote, automated, or off-canvas control.
I completely understand the passion behind this—I volunteer my own time to maintain and upgrade a free to use GH plugin (DKUI). It is incredibly rewarding, and I gladly do it because the tool benefits my own development.
However, I have realized that as a user base grows, so does our architectural responsibility. The longer a plugin is “in the wild,” the more people rely on it. Some of these users eventually base paying client work on our tools. Because of this, a primary goal in my own development cycle is ensuring that new feature upgrades do not break downstream workflows or isolate the components from the broader ecosystem.
Thank you for all the amazing work you put into your plugin. I hope this feedback is helpful for its future evolution!.
hi @Petras_Vestartas
I installed OpenNestusing the Package Manager. It runs successfully inGrasshopper 1, but it does not run in Grasshopper 2. Is there a way to install or make it work in Grasshopper 2? (All versions are up to date. Windows – Rhino 9 WIP,Rhino8)
That’s great to hear. Having the rotation constraint as a parameter of each element would actually be even more flexible. Since the API already supports it, exposing it through the Grasshopper interface would be a very valuable addition. It could also reduce computation time by limiting the number of rotations evaluated for certain parts while still allowing unrestricted rotation where needed. Is this something you are considering implementing in a future version?
Out of curiosity, how do you envision passing that information to the nesting component? Through a dedicated rotation input, or perhaps as metadata attached to each element similar to key/value properties?
Added “Rotation” option at the geometry level. You can control element rotation. In the screen shot below I’ve set rotations to 4 for rectangles (90 degrees rotations), other elements are rotated 360 times (1 degree rotations):
The options works in both ways: a) when options component is connected to the solver, b) or using drop-down menu. The “Options” component will adapt when connected to a solver, as parameters are different for each case. Other wise you can change the layout of parameters by the right click of the solver input:
Grasshopper 2 is available only on Rhino 9 WIP, and you need to install it manually. But when you install OpenNest through package manager, you need to manually load opennest_gh2.rhp file from the Plugins, you can find this file by searching on your pc, I use “Everything” tool:
.
