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 canvasunless 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
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?
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 !!!
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)
This goal object do not reset with the reset of the solver , 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…
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)
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)
, but sending a 0 value to the length input works as workaround, for now…
