Hops not working?

This definition:
2023-02-10 13_37_45-Grasshopper - hops test
hops test.gh (2.7 KB)
(set as tree acces = false)

If used with hops:
2023-02-10 13_34_55-Grasshopper - unnamed
2023-02-10 13_35_45-Grasshopper - unnamed

(referenced are 2 simple circles intersecting…)

I’m doing something wrong?

Will need the code that calls this Hops function to test it. Does “Referenced Circular Curve” mean they are from a Rhino file? What happens if you internalize them in the caller?

hops test 2.gh (12.2 KB)

I haven’t used Hops for quite awhile, has the “RH_OUT:paramID” convention been deprecated?

I’ve never used Context Bake. When I disabled it and added a group labeled “RH_OUT:RUnion” it started working, though the Hops ‘curve’ output remained until I deleted the component.

hops test.gh (2.4 KB)

hops test 2.gh (5.8 KB)

When I tried moving Context Bake to the caller (hops test 2.gh) it does nothing. I may have messed up the files so they don’t match the images… :man_shrugging:

Yeah, those work but you can try these. Reset the Hops Path, of course.
hops test b.gh (3.5 KB)
hops test 2b.gh (5.8 KB)

Context Bake says it is for GrasshopperPlayer?

1 Like

Same here.
But I remembered seeing this some time ago:

In this ^ picture it seems to already work…

And I directly expected for it to work like that.

@stevebaer @scottd @AndyPayne … who was charged to do this?


From a year ago… maybe out of date now? I don’t have the patience to read all that documentation, I learned Hops by reading forum threads and examining code. :wink: But yeah, I see this on that page:

Defining Outputs

Hops outputs can be defined using the Context Bake or Context Print components. The name of the input parameter on either of the Context components will be used as the name of the output parameter when Hops gets computed.

The convention of a group with “RH_OUT:paramID” has always worked for me. Hops is pretty cool.

Indeed. Absolutely!

But, it would makes sense if GrasshopperPlayers and Hops would rely on the same “anchors” of a function.gh … and using a group with a particular name (“RH_OUT:paramID”) doesn’t seems a definitive solution.
Also, it’s written there, on an official page :sweat_smile: to use Context bake / Context Print (and maybe add a “Context Object”? for numbers/vectors/others that shouldn’t be cast to string to avoid rounding or other problems…)

1 Like

You should be able to use either method. You can use the “group” method with RH_IN:param or RH_OUT:param or you can use either the Context Print or Context Bake component to create an output parameter. Either method should work. If this is not the case, please provide a simplified example and we’ll have a look.

First post.

When I saw “Bake”, I expected it to bake the result into the Rhino file. Poor name choice.

It does bake depending on the context that it is being used in. When being run in the grasshopper player, the geometry is baked to the Rhino document. When being run in a remote compute session, the geometry is baked to the json response.

The group names for input and output have been deprecated, but we still support them.

When I moved Context Bake to the caller (hops test 2.gh), expecting to bake the Hops result, it did nothing.

I’m trying to get caught up on this thread. Is the context bake not working?

A simple function.gh that uses a list of curves (“At most” = nothing or 1000) doesn’t work.
It works if I set tree access=true, but that is a different behavior.

Using “At most” = nothing or 1000 correctly translate into hops reading input “as list”, but then it doesn’t work.
(See error messages on my first and second post)

Does “remote compute session” include this context when both files are in the same folder? I’m not aware of any JSON, is that under the hood? Seems more confusing than necessary. I always thought the group names (“RH_OUT:paramID”) were awkward but no more so than Context Bake which looks very weird. The “average user” (me) doesn’t care about implementation details.

Sorry, my terms were misleading. This is really all under the hood. Hops works by calling a separate instance of an application which receives a request in json form, processes that request, and sends a response back to hops in json form. This instance can be non-user interface version of Rhino running on your own computer or another computer. It could also be a python server that knows how to work with the hops communication format.

I agree that the group names are awkward. They were also only used in the context of hops.

Naming is hard. We initially called the inputs (Get Point, Get Number,…) contextual inputs which is why we ended up with context bake. Is there a better name to use?

Contextual Output … ? Maybe.
With the same right click thing to specify the type of geometry and/or string, int, number, color, etc…

There is also a context print that outputs strings.

If there is a better name to use, I’m all for it. This thread really began as a bug report and I’m going to try and get this into our bug system so we can attempt to repeat it and fix it.

I worked with JSON extensively writing web applications so I understand you, but as a user, I don’t care. Same goes for list access vs. tree access - it’s Grasshopper, tree access of course, even if it wasn’t implemented when Hops was first released. I have no knowledge or experience with GhPlayer so having it bake Rhino geometry, in the conventional sense, is odd when there is no Bake component in standard GH. What about layer and other baking attributes?

“Contextual” doesn’t mean anything, in this context. :wink: Something like Response makes sense for Hops but maybe not for GhPlayer. Is there any good reason from a user’s POV that they must be the same? By the way, I don’t see any reason to have a right-click option for type of geometry. Can you imagine how painful it would be to have list/tree and type options on all GH components? Not good.

@maje90 I just logged this into our bug tracking system at


1 Like