yep! that’d be very helpful.
and you can see the ‘selection window’ drawing as I drag in this video (2 solvers in 1 definition)
made me think of an idea where objects would carry an ‘optional’ info (such as rotation axis). here’s an example of what could be an interesting way to expose the menus (depending on the tool ; )
In general I recommend against having multiple instances of Kangaroo running at the same time in one GH doc.
I don’t think it generally has a huge impact on performance, but I just can’t think of any application where there is an advantage to running separate simultaneous solvers.
If it is about getting access to different groups of points/geometry separately, you can use Entwine on the input and ExplodeTree on the outputs like this
rgt! getting multiple inputs to work is not a prob, the video above required the output from one > rotate it > and get referenced again in a second solver
Ah, I think I understood now why you needed to chain solvers together in that way.
Here’s a goal which allows keeping some sliding points on an active curve which is moved by other goals, but where pulling the sliding points does not move the curve, so it can all be done in a single solver.
It was an interesting challenge - working through it gave me some ideas about how to make setting up systems like this with a mix of 1-directional and bi-directional dependencies simpler for future versions.
This is because people can have Kangaroo in different folders on their machines. You can close the message then right click the script component, choose manage assemblies and set the folder. The location is usually one of the ones listed here
Hi @DanielPiker
Where will it be on Mac?
I can’t see it in : /Users/akash/Library/Application Support/McNeel/Rhinoceros/7.0/Plug-ins/Grasshopper
There is no Component folder, only Libraries to put add ons in…?
so I think the ‘Script’ component doesn’t work with GH Player
do you think the tweak in the solver (to avoid selection window during multiple solvers) can be expected?
The Script components should work with the GH Player(after you’ve saved them with the assembly reference location resolved) - are you getting an error?
(Also - we’re looking at changing things for future versions so the Kangaroo dll file is located automatically)
I’m going to see if there’s anything that can be done about the selection window with multiple running solvers/grabs.
However, my preferred solution would be to somehow make it easier to setup these sorts of directional dependencies in a single solver instance (but I see that chaining them together in this way is a smart workaround for now).
Ah, I see - In the file I shared above it isn’t already set up as a GH Player definition with Get and Bake components.
Here’s one that is onActiveCurve_player.gh (26.7 KB)
One funny thing here is that if the only interaction you want comes from the grabbing, and the geometry is already internalised in the definition, you still need to include some ‘Get’ component to make the GhPlayer work.
In this definition there’s a dummy ‘GetNumber’ component that isn’t actually used, it’s just there to stop the command completing before you’re done interacting.
that’s really odd! I did a version where geo is needed, and got no results (see the file)
(just draw the ‘diagonal’ line and a reference a small ‘square’) onActiveCurve.gh (18.0 KB)
I noticed I needed to turn the ‘Realtime’ option off for the GetLine, otherwise it creates lots of extra points in the sim as you draw it. It also still needs that dummy number input to stop the command ending early.
cool! I matched my def to yours & still have the issue (something funky going on somewhere). gna mess w it a bit & see what’s breaking
but def gd to know script components work w the player ; )