I’ve been using Hops recently and was delighted with the new functionality… until now. The trouble started when the geometry being returned (a NetSurf ‘Untrimmed Surface’) was rotated 180 degrees from how it was created. I forged ahead, modifying how the ‘NetSurf’ is created until Hops stopped returning the surface at all. No error messages, no clue.
Other Hops code still works and a simple round Boundary Surface added to the same file returns as expected. There is no indication that the NetSurf is invalid, Zebra analysis looks great.
My heard hurts from banging against this wall, The creative process grinds to a halt. What is wrong?
P.S. Though I disabled Hops cache (right-click Get Number component), changes to hops_set_2021Sep29b are not recognized until the Hops Path is reset - to the very same file.
Furthermore, changing Path does not generate new output until the Get Number input is modified, even though a new output (‘RH_OUT:round’) is shown immediately.
A minor detail is that Get Number output ‘roof’ is disconnected when the ‘round’ output is added. I can handle that but losing the ‘roof’ geometry is crippling.
I’m able to repeat that you don’t get anything back for the “roof” output and am trying to track down the cause.
Edit: Something very weird is going on. I modified your definition to output the curves fed into the NetSurf component and can see them show up when using Hops. When I feed those curves into NetSurf on the definition that contains the hops component, I also don’t get a surface created.
Yeah, it sure looks that way to me. Thanks very much for looking into this, Hops was really, really great until I hit this brick wall.
To avoid being blocked, I by-passed Hops and copied all the code into my model that called it. I’ve got beautiful results but just now I copied the code back into ‘hops_set’ and it still doesn’t work.
This is very interesting and perhaps significant? I added a third ‘U curve’ down the middle (cyan group). It appears to work fine in ‘hops_set’, with better curvature and perfect Zebra quality when baked.
This is similar to the “rotates geometry” reference in this thread title where, before it stopped working completely, the surface I was seeing in ‘hops_get’ appeared to be rotated180 degrees from how it was created in ‘hops_set’. Maybe it wasn’t rotated but the ‘U curves’ were in reverse sequence?
P.S. Oh yeah, look! If you increase the ‘R_Win’ slider (to ~11.4 in this case), the perimeter curve from the EllipseBeam cluster bulges in the positive Y direction, as intended.
So far I’ve figured out that the curve coming out of your cluster is not the same when running as a remote definition. I’m still trying to determine why that is happening.
AHA!!! That’s it, my bad. That cluster is very old and was poorly written to work only with a vertical plane. It was sorting the half ellipse curves by ‘Z’, which makes no sense when both curves are in the XY plane. Changing it to sort by ‘Y’ instead of ‘Z’ allows Hops to pass the surface and curves correctly. WOW, thank you very much. Very weird that it seemed to work properly until trying to pass the geometry through Hops. I’ll re-write it to take the ‘Pln’ (Plane) input into account when sorting.
I happy you solved your problem, but I’m still going to investigate this issue further. I don’t understand why the “Sort List” component is generating different orders of output when run in different environments.
At least I can sleep better now knowing this is working for you
Just for historical purposes of this post, I was debugging this by making a RH_OUT component for curves and moving that component back up the graph until I figured out where things differed. I had to explode the cluster to get back to the sorter as the cause.
Thanks for your patience on hops. It is going to be very powerful, but there are still nasty little issues like this that we need to figure out as well as make easier to debug.
Given the discovered sorting flaw (by Z instead of Y) in the EllipseBeam cluster, the mystery to me is why it appears to work properly when used “inline”, without Hops?
Agreed, it completely changes how GH can be used, with special significance for larger GH models.
Back in R5, I had a HUGE GH model for all the pieces of this complex sailboat design, which was marvelous when I could click two buttons (‘Delete’ and ‘Bake’) to regenerate the entire boat. But it was absurdly complex to work on that file so when I got R6, I split it up into manageable pieces that exchange geometry and parameters using Data Output and Data Input.
Hops is way better in several ways but from what I can tell, it works only with single request parameters? Would be nice to accept multiple name/value pairs, like a web REST API/service:
The crossbeams are created using the old, original EllipseBeam cluster that relied on a vertical XZ plane. I reused it for the pilothouse roof (XYplane) without remembering the internal sorting issue.
Hops is using a REST-ish API for sending requests to another process for solving. I’m not sure what “multiple name/value pairs” means. Can you elaborate on this or provide a specific example? Thanks
Maybe I missed it, I could have tried it myself first (and I will), but I didn’t see examples of more than one Get Number parameter, for example, that would affect the shape of this roof? I just interrupted myself to give it a go and I don’t see any way to make that work?
There are eight parameters that affect the shape and location of this ‘roof’ in my ‘hops_set’ demo, but I can pass only one of them from ‘hops_get’ through Hops, right?
P.S. I was thinking of a new Hops component that can have multiple inputs, similar to List Item but with named inputs and outputs. The type of each input could be settable.
P.P.S. Similar to Data Output actually, which has user-defined, named inputs but with a serious flaw. Apparently name/value pairs are not used so when inputs are deleted, for example, the wires connected to the corresponding Data Input component get all messed up.
You can have as many “Get” components as you want. You do need to rename the components to something different than “Get Number” so they have different named inputs in the hops component.
Oh? Cool! I didn’t see any mention of that in the docs but again, maybe I didn’t try hard enough?
Examples always work best for me.
P.S. Wait a minute… If I have multiple Get Number components and they all have a ‘roof’ output, how do I know which one to use? I’d love to see how this works?
Our documentation is severely lacking with respect to hops, compute, gh player and these new “Get” components. We do have someone who will be digging into this in the next few weeks with the goal of improving our docs.
There are so many features that can currently only be discovered by scouring this forum which is exactly what you are experiencing.
More info - it’s too much work to build a simple demo of this but it’s pretty clear that some “friendly assumptions” we have grown used to in Grasshopper don’t work when the same code is called via Hops. The sorting issue may be only the tip of the iceberg.
In a different model, I’m seeing variations of this error:
Data conversion failed from Surface to Curve: component “Disc” (5780c1b9-0920-48a1-8ee0-fc8ab5435221)
When I run the surface through a Crv param first, I get this error:
Data conversion failed from Surface to Curve: component “Crv” (929f3aab-6251-4913-b149-68f482e82d3b)
I can work around these things but when functional code breaks only because it’s called via Hops, there is a deeper problem.
P.S. Here is the work-around (red group). which isn’t necessary except when called by Hops.
To see the error, unplug both wires from the red group Join and plug them directly into SrfSplit ‘F’ output, then try ‘hops_get’ again. Or try replacing the red group with a Crv param which also works fine in ‘hops_set’, as it always has, but causes the error via Hops…
