that’s cool that you don’t get the ‘selection window’ during drag!
Do you mean when you have a single GH definition with multiple solver and grab components?
It sounds like something I need to fix in the mouse event handling.
yep!
just curious: is there any difference between feeding everything into one solver vs
splitting them (say, for the sake of organization)? responsiveness-wise.
After searching I have nothing relevant, unfinished ideas.
This was the spherical slider that returns a vector but it doesn’t work well and I’m afraid to look inside.
14 Likes
I wonder if this is kinda what you had in mind:
I think one obvious thing is you can’t have unlocked geometry behind (I locked everything except the part that’s getting work done on). If somehow, locking/unlocking is available via GH Player, that’d be really useful.
23 Likes
Wow, this is great! Keep 'em coming. 
Kinda makes you question the overall Rhino interface and UI interaction as it is.
5 Likes
Very cool. To be honest, I’m not sure what I had in mind…I think the question was more of a provocation than anything else. This clip helps me though!
In your clip, when you click on the right-hand object, it exposes interface for the left-hand interlocking object. Intuitively, what I would imagine happening when I click on an object is that it would expose an interface for itself. What your clip is really helpful with is questioning relationships…the hinge is such a great choice too.
What if one clicked on the right-hand object and it exposed controls for the hinge? What would you imagine happening to the interlocking left-hand object? Would it also show the left-hand object’s abstracted interface (sliders) changing?
PS: I realize the scope of my questions here might go a bit beyond what the GHPlayer was intended to do.
@stevebaer I’m trying to write this up as a YouTrack item, but I’m struggling with how I might explain it there, as far as expected behavior. I wonder if you already have an idea of how you’d do this and just logging it would be enough?
Sorry, I’m limited in creativity here. I can’t think of a clean way in GH to set up logic like this
If the issue is just with accidental selection of other Rhino objects behind the Grasshopper geometry you are interacting with, then I wonder if maybe a modified version of the Grab function could help here.
It currently ‘steals’ mouse events from Rhino only if a Grasshopper point is within a certain range.
Normally it would be very annoying if whenever Grab was running it stopped you selecting regular Rhino geometry, but it sounds like that is maybe what is wanted here, just for the duration of the GH player command.
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 ; )
14 Likes
Also I forgot to answer this-
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
entwineexplode.gh (20.8 KB)
1 Like
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.
onActiveCurve.gh (22.7 KB)
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.
13 Likes
do you know what this mean? (opening your gh file)
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
super cool! never tried ‘collision’ & ‘support’ bits before! much to explore!
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…?
Thanks a lot
Akash
/Applications/Rhino 7.app/Contents/Frameworks/RhCore.framework/Versions/A/Resources/ManagedPlugIns/GrasshopperPlugin.rhp/Components/KangarooSolver.dll
I’m curious. For more “complicated” parametrically-driven models, how would you imagine that they expose their interfaces?