Using Kangaroo Grab instead of Gumball

Big question:
I have a set of Brep spheres that, for reasons probably not worth explaining, I’d like to move around in the screen using by using the K2 Grab component

when 2 (or more) spheres touch / intersect each other, I would like them to snap to a given distance based on their radius

as far as I have understood, it’s not ok to have multiple Kangaroo solvers on the same canvas unless they are chained and have dedicated unique goals… but I guess I’m missing something important because it’s not really working as it should :slight_smile:

it sort of works when the first intersections are found, then sometimes it doesn’t work anymore if a sphere already “intersecting something” is pushed to find a new intersection… probably this is not the right approach? :frowning: (21.0 KB)

any help is really appreciated!

… yeah, the situation is pretty… “tangled”

Try this: (35.2 KB)

This method is clunky, heavy, slow… as there are many additional points in the background.
A custom goal object would be best.


well, this looks very promising!!!
do you know if it’s possible to supply the Magnetic Snap goal a different Range value for each Point? I will investigate on this

I would like the different Spheres to compenetrate each other by a given ratio, let’s say 0.6 * Radius of the Sphere itself, so I can just scale down each meshSphere on its center by 0.6 and use them as “skeleton” → then orient on their relative centers the 1:1 non-scaled geometries… super nice!
Thanks a lot @maje90 !!!

Hi @inno
This might need a custom goal as @maje90 suggests. I’ll try and put together an example tomorrow.


thanks a lot!

It’s always you, Daniel… you provide us with code but then “nobody learn” (speaking to myself).
This time i’ve tried, using the “BreakableLines” goal as starting point. (New scripting examples - Grasshopper)

StickySpring (22.6 KB)


This goal object do not reset with the reset of the solver :no_mouth: , but sending a 0 value to the length input works as workaround, for now…
@DanielPiker how can I fix this?

Also, the c# script would give me a warning:

“1. Warning (CS1701): Se il riferimento all’assembly ‘RhinoCommon, Version=6.33.20343.16431, Culture=neutral, PublicKeyToken=552281e97c755530’ corrisponde a ‘RhinoCommon, Version=7.11.21264.11001, Culture=neutral, PublicKeyToken=552281e97c755530’, potrebbe essere necessario fornire i criteri di runtime”

so i used a “this.Component.ClearRuntimeMessages();” to hide it… still not that good…

Is this something you still need?


wow, just AWESOME :heart:

I have used my master-coder skills to add this and mimic some sort of compenetration
(randomly adding that line everywhere like a blind monkey: always works)

omg, this is so unbelievably nice, I’ll play with this FOREVER, thaaaaaaanks!!!


Nice work @maje90!
Thanks for sharing this.

About having goal objects reset -
The way you’ve done it here is good. You can also use an extra input on the goal component and connect that directly to the reset toggle.

(here I haven’t changed the code at all, and the ‘x’ input isn’t actually used anywhere in the script. It’s just that any update to the inputs of a component calls its RunScript, which means a new instance of the StickySpring object gets created.)

The other existing Goal objects which have a state that they remember from one iteration to the next, but can be changed from within their Calculate method (PlasticAnchor, PlasticLength, LiveSoap, Bomb) use a similar thing, and need to be connected to the reset button if you want them to clear when resetting the solver.

I feel this setup isn’t ideal, as it is a bit messy to have to always wire them up to the Reset.
When I was designing Kangaroo2 and the way the goals/solver classes interface I wasn’t thinking yet of these sorts of ‘stateful’ goals, so goals only have access to the particles.

Something I’d been thinking of changing that could be helpful here would be to also pass the iteration number to goals when calling their ‘Calculate’ method. That way a goal could know to clear its stored values such as plastic length when the iteration count is zero (without needing extra wires or inputs to the component).
This also opens up the door to goals which automatically ramp up or down their strength over the course of the simulation without the user having to change sliders, and other types of choreographed animations.

As for the warning about version numbers - I’d got used to just ignoring it, but I think it might just be a matter of changing some reference settings when Kangaroo builds. I’ll try and sort it out.
(edit - I just checked your file again and see the referenced assembly was set to the KangarooSolver in the Rhino 6 directory - I don’t get any warnings if I remove that and replace it with the Rhino 7 one)


Nice, thanks!

Make sense! Looking forward that!

One step at time.
If it worked, it means you are comprehending!
Everybody start somewhere.

The effect of the spheres compenetrating a bit is indeed cool!
Anyway, you can obtain the same with a multiplier:
2021-09-30 14_27_31-Window

… also, i forgot about this:

it seems relevant…


Add some sort of random motion to one ball and watch it all coalesce into an organic blob, then shrink wrap a mesh around the whole lot!

1 Like

that is really close to the final idea :slight_smile: I’m trying to make the generation of bubble clusters super handy and very simple