A new version of Hops (0.15.0) is now available via the package manager.
What’s new:
You can now internalize referenced definitions inside a Hops component (if the file is saved on a local file system). Similar to internalizing geometry in Grasshopper, when you internalize a definition it means that it removes the reference to the external file and instead serializes the definition inside the Hops component. This means that once a referenced file is internalized, you no longer have to share the accompanying referenced definition along with the Hops file. This should make sharing Hops functions with colleagues and members of your team much easier.
As usual, the change log for this build can be viewed here
It showed a distinct Tree input access, but perhaps it was later removed? Nonetheless, what is the proper way of setting Tree input when using Hops? I am testing Split Brep Multiple component, but it will flatten my input tree structure as shown in the screenshot. I am expecting a tree with three branches, two Breps in both.
You need to update your Rhino to service release 7.19.22130.15001 and/or 8.0.22131.04306 or higher. Once you’ve updated Rhino, all of the contextual Get components should have a Tree Access input.
Thanks for the new functionality,
I´m testing it and I´m running into a problem with parallel processing when setting Tree Access to true: the number of compute proccesses using the CPU is limited to one, so the definition becomes as slow as out of Hops.
Is there any solution for that?
@TrialAle I don’t think there’s really a solution for this. The reason is that when you set a parameter to use Tree Access… it’s telling Hops that this particular input is going to be expecting a Data Tree to be passed in. It takes that entire tree and makes a single compute call to solve the definition and return the result. This is a little different than item and list access. For example, if you set the At Least value to 1, then you’re essentially telling Hops that it should consider this parameter as Item Access. You pass and item into it and it makes a single compute call to solve the definition. Similarly, if you set the At Least value to something larger than 1 (or leave it unset) then Hops will treat this parameter as List Access. Again, you pass it a list and it consumes the entire list and makes a single compute call to solve the definition. Now, let’s say you have the At Least value set to 1 so it’s expecting Item Access… but you pass it a list of 10 objects. The expected behavior here is that it makes 10 separate compute calls where each item in the list is treated as a single item. In this instance, each of those 10 calls could be sent to a different child process and run in parallel (depending on your server configuration). But, when you set the input to Tree Access, it’s only going to make a single call and use the entire Tree in that compute call. Does that make sense?
Hey all, I just updated for the hops 0.15 version and that broke my hops components. I have noticed that just one of the inputs (a get geometry) was always saying “this input needs at least one item”. But I was putting one or more itens (as list) and I also had no maximum for that specific input.
What solved the issue was to put tree access as true. I just wanted to point out that before the list access was working without that. Is that to be expected?
Hi @natasha.catunda This is a bug that was just fixed in the latest release 0.15.3. Could you try upgrading to that version and see if that fixes things?
Hi @AndyPayne
Not really. I actually noticed I had that version already, cause I literally just updated hops. Anyway I tried to reinstall everything, reboot etc. I can again reproduce the issue: if I put tree access to false (images below), then I have an issue, if true, it works again.
What is weird is why the problem comes ONLY with this input. I have tried to put any input component and it comes the same issue. I have another “get geometry” that has absolutely no issue with the list input. The only difference between the two of them is that one is a list of polylines and the other a list of surfaces.
Here the other “get geometry” that is working with a list input:
There you go the examples with list access. I tested again and the hops would work with tree access for the geometry part. hops.gh (17.2 KB) Definition_with_hops.gh (17.5 KB)
