Graphs can turn into a spaghetti mess fairly quickly and I’ve found that clusters make it more manageable by breaking nodes into manageable and reusable chunks but I wish they were easier to use. If you turn a collection of nodes into a cluster you are likely to end up with duplicate inputs so what I do is keep converting it into a cluster until all the inputs are named and then inside the cluster remove the duplicates. Couldn’t Grasshopper do this automatically?
Secondly, sometimes I would like to change the name of inputs and outputs but changing a cluster input/output inside the cluster doesn’t change it on the outside. I think it would be better if the input/output labels where the same inside and outside the cluster as well as for cluster instances. I’m sure there are edge cases where you would want them to be different but most of the time you don’t.
Hi Mark,
is this what you mean by duplicate inputs? (Cluster 1 in my image)
The way I go around it, is to join the input streams together before clustering (which I do anyway, regardless if I’m clustering, just makes things a little cleaner). And that’s cluster 2 in my image.
Yes, but it’s not that sophisticated. As suggested above, you have to set parameters (the components with the black hexagonal icon) to avoid that problem and also to define the type of data you expect to receive. At a conceptual level, the inputs and outputs of internal processes are not the same as the inputs and outputs of the parent component, they are different entities bc the context changes. This is also a good practice to do in groups, is another way to encapsulate.
To modify an input or output of the cluster, I always copy the hook, I modify the copy, I delete the original and I plug the copy. This way you avoid any problem.
although encapsulation is something very important and useful, I would just rarely use Clusters in GH. This is because clusters are not well implemented.
One reason, if you open a cluster you basically open a new document. Nothing in Grasshopper is more confusing as having more then 1 document open. Then you might have two version of the same cluster open. Also debugging is difficult. In order to see where something went wrong you almost always are required to open the cluster. But also cluster maintenance is a problem, you change one cluster in definition A, but this can be something where the same cluster in definition B breaks. if you do not keep attention, and blindly apply those changes for your other documents, you really get nasty errors.It easily break (… quite often when you don‘t have time for this).
Before I moved to script as much as possible, I and my former coworkers made rather big, unclustered, but well structured definitions. On a longer term, this is the better way. At least in my opinion!
This is because clusters are not well implemented.
I agree that clusters could be implemented better. If you’re not re-using sections of your definition, groups are probably good enough. But I find the parametric nature of clusters allows you to do things that would be really tedious otherwise. If you make your clusters flexible you can re-use sections of your definition for different situations just by changing a few input parameters.
Before I moved to script as much as possible
It would be interesting to do a whole definition in code but I find the instant visual feedback of nodes quite useful. It is possible to provide instant visual feedback in code like Observable or Luna - which has dual representation - node graph and code.
I mean you can group a set of components and simply copy this group wherever you want. There is literally no difference, and this is what we did because of the 1 document rule we gave ourself. But what makes actually a definition so big? There is a lot of components used to do data management. 1/3 to even 2/3 of a definition is exclusively used to access and organizing data.
Scripting in Grasshopper is not about writing 1 single component. Its about writing a bunch of components following a greater purpose. One setup I often did was, when doing generative patterns on cars:
• Process input
• Create a grid/ curve basis
• project/pull/morph the grid to the shape
• build front surfaces in 3d
• build side surfaces/flanges
• fillet or at least prepare surface fillets
• cut or close the back and to the frame
• prepare data to post process manually
Because of the clean encapsulation the output generated was whats enough to visually confirm the algorithm. If thats not enough you can quickly override the preview and add certain geometry to render. Of course writing scripts takes more time, but it pays off in the end. You not only get better results, your code is better readable and much more reliable, since conditions are much easier to integrate. On the other hand, if you can do things shortly and nicely without scripting, nothing speaks against doing it like this. You could also tests things with native components and improve and refine by code in a second step.
However at least the job I was doing back then, creating quality results strongly overweight quick and time critical workflows. And this is a philosophy you rarely see in the Grasshopper world. In my opinion its not about creating endless combinations in a very short timeframe to explore a design. Its much better to already have a clear idea which only needs to be well implemented by the help of algorithmic modeling. It also helps of course to know what should be done in GH and whats not.
