Write Rhino Commands in Grasshopper

Turn your Grasshopper definitions into Rhino commands

The latest V7 WIP contains a new “GrasshopperPlayer” command along with several new components for this feature. The GrasshopperPlayer’s intent is to allow a definition to be run as a normal Rhino command.

Here’s my “show and tell” presentation on the subject during our weekly development meeting.

PLEASE NOTE: This is a SUPER EARLY prototype that will go through a lot of changes.

As always, I’m interested in feedback and suggestions.

41 Likes

A Value List Parameter would be great to support this !!!

To be able to pick = select an option on the command prompt…

Andres

2 Likes

That is a good suggestion. We are considering renaming the inputs to

  • GetString
  • GetPoint
  • GetNumber
  • GetInteger
  • GetBoolean

A GetOption would make a lot of sense here.

1 Like

I can see a GetOption component that takes a list of Option components (e.g. SingleOption, BooleanOption, IntegerOption, NumberNumber, and ListOption) as input.

RhinoScript implemented a GetOption method in this manner.

https://developer.rhino3d.com/api/rhinoscript/user_interface_methods/getoption.htm

– Dale

1 Like

We can probably just infer the type based on the input.

I think this has really a great potential! Great work so far!

As a suggestion, multiple inputs could be integrated as multiple options like with standard Rhino commands. Perhaps this could be based on Grasshopper groups?
In this way from the start the command could show the solution with the default values that are set in Grasshopper, and this could add to the interactivity.

However, I’m looking forward to seeing how this evolves!

Wow… amazing!

If I extrapolate this to its logical conclusion after it has developed into a mature function, looks to me like learning/using scripting for the average person is pretty much going to shrivel up and die…

I think that’s what Vanessa/Rajaa/Steve hinted at just near the end of the video.

1 Like

I think they mention something at about 17 minutes. However when they speak about interactivity, I think they are referring to having editing capabilities even “after” the command has run, even with a UI panel like the Remote Panel - which would be great, of course!

I was thinking something less complex: grouping different inputs/outputs in a single prompt (like when you launch “Circle” and see all the different options - Deformable, Vertical, 2Point, etc. ), while - if I’m not mistaken - right now each context input results into an individual prompt.

With a single prompt with multiple options, since the inputs can have default values, the command could show the “temporary” solution with the default parameters, and update it when the user changes one of them.

But I understand these are details that can be developed later.

Again, I think this is a great development and I can already think of several situations where I could have used this system with clients/users.

1 Like

I thought about and chatted with others about command line options for quite a while. The conclusion I came to was “this seems hard” and that it would be best to tune up and get the current set of components working as smooth as possible first. My hope is that as we play with these new toys, we’ll get a better feel for what can be done to support advanced features like command line options.

But then who am I going to talk to :slight_smile: By the way, we’re trying to figure out a system for packaging python scripts as commands via Yak as well. All pie in the sky ideas at this point though.

3 Likes

Thank you for the feedback Steve. It’s just good to know that this was/is taken into consideration, I understand it’s better to have everything working first, and only then focus on more advanced features.

Keep up the great work!

What about a ListBox input, maybe along with other *ListBox’es, just like in rhinoscriptsyntax ?

Great job guys!
Maybe you could also enter a Boolean value to activate the context bake, so that we can better use Kangaroo

Can you explain a little more why this would improve how you work with kangaroo?

1 Like

Hi @aurelio1
Here’s the Kangaroo definition that’s shown in Steve’s video above:
dp_playertest2.gh (17.0 KB)
It doesn’t need any special way to bake - you can just hit enter or right click to end the command as normal.

Thank you Daniel.
The boolean for bake would be just to use some tools that for now I don’t understand if they can be used, for example the grab of the points or faces

Grab actually does work with the Grasshopper Player as it is now.
For the Context Geometry component that gets the input you need to make sure the ‘At most’ setting is blank, so it is unlimited. If it is set to 1, the command closes before you’ve had chance to interact with Kangaroo. I find it’s also helpful to turn off the layer of the input geometry after selecting it, so it doesn’t get accidentally dragged in Rhino while trying to use the Kangaroo grab.


grab_playerexample.gh (17.3 KB)
7 Likes

Thanks, all clear now

I’ve totally missed this thread. This is super interesting, wow!

// Rolf

1 Like

How I can get the feedback of this panel from the bellow definition? Needs “Viper” components. I just want to find open curves and to have some feedback from the panel.

OpenCurve_finder.gh (7.1 KB)

Hi -
You can use the Context Print parameter to create a report that will be shown after the command has finished. It’s not possible to get feedback during the time the command runs.

You can use the Closed component to test if curves are closed and filter out curves that you don’t want to use in the rest of the definition.
-wim