WISH: different clusters

Hi all.

Problem: working with datatree is fine, but with very complex datatree one might spend too much time aligning the data instead of actual coding.

Current clusters: just a portion of the whole definition, no difference from normal workflow.
Hops: we can set inputs to work as item, list (or datatree with some trick), but the problem is you can’t see the script working while editing the content of hops (it’s another .gh file!)
You can’t explore/test the hops code until you run everything at once.

With c#/python scripts we can set inputs “as item” , “as list” and “as datatree”.

Currently clusters still require datatree management inside of them. The “only” advantage of clusters is you can copy them, they are linked, and to make visual order on the canvas…
Hops instead can really help you with the datatree management, by simply “cutting down” by a level all of your trees structures… but they blind you while coding because you have to use “GetPoint”, “GetSurface”, and those components output nothing.

Solution (kind of):
some sort of clusters that have inputs with different pre-set of inputs (inte-list-tree) where you can double-click to enter inside and code while seeing the geometries of the actual current document! … maybe with a variable iterator to change the current “run” that is being computed.

Sorry for the textwall. I hope this is decently explained.

@DavidRutten

1 Like

It would mean that clusters can no longer be exploded in place. Granted, that’s probably not something people do a lot…

I think it makes sense to have these options on clusters and in general to make clusters appear and behave even more like regular components, and that includes giving cluster creators similar options to component developers, for example ways to set specific errors or warnings.

1 Like

Yeah, current clusters are a really good tool.

Maybe what i’m looking for is a better way to use hops.
Hops already behave as I need, on the computing side. But it’s really tricky to use them.
You can’t see the effects of what you are coding, losing many of the advantages of visual programming…

Rephrasing:
WISH: ability to create, edit and use hops with the same easiness and UX as clusters.

You can pass data into your “get” components that are used in hops to work with and experiment on these gh files before they end up being used as hops functions. There must be more to this that what I just wrote.

I know that.
(but sometime that result in the code misbehaving, I usually use hops with nothing at all connected as input to those “get”)

Editing the code?
Your main definition have referenced geometries, that change often. What you feed to the hops component is a derivated gometry, volatile, dynamic.

The hops .gh file is a separate file, and there you don’t have the data that is fed to the hops component.
You have to manually extract the single item from the list and a single branch from the datatree, internalize them, and copy them inside the hop. And this for a single “run” of the hops component.
I’ve done this… I tried.
It’s not suitable.

But the potential is there.


For not-too-complex definition hops is already incredibly useful.

We could potentially save a series of inputs as test data when running a hops component and then allow editing the actual hops gh file with this test data.

I imagine the setup of item/list/tree to be done outside the hops.
Entering with doubleclick, and seamlessly find your data (the data you just saw outside the hops) to be inside the hops (but respecting the item/list/tree to partition the “runs”).
Very like how clusters works currently.

I’m sure that to achieve this a lot of work is needed…


I’m not using hops where they could best fit… because of how they need to be handled.

That would essentially be the experience I imagine could be achieved. I was thinking more about the technical details of what would happen behind the scenes.

1 Like