Feature Request - Cluster activity

Hi,

I had two ideas for Cluster functionality within Grasshopper that I thought would be immensely helpful. I'm not sure where to submit feature requests, so if there's a better place to post / email, please let me know.

Also, I'd like to preface this request with a great deal of gratitude and thanks for creating/working on this software. So - thank you!

1) Variable parameter insertion for clusters

Right now, if you have a cluster and want to add an input/output from the parent document, you have to open the cluster add an input/output, close the cluster, and hook up the cluster. This is all good and well, but if the cluster takes a few seconds to execute, adding/removing clusters becomes pretty cumbersome.

Instead, if there the variable parameter capability was added to cluster (ala the C#/VB/Python components), it would be great. I'm imagining the functionality being:

You zoom into the cluster, and click on the 'plus'/'minus' buttons, which adds/removes an input/output (a generic input param) within the cluster, in an arbitrary location. You can then hook parameters up, and then double-click to enter the cluster. After you find the input components, you can continue hooking them up to the rest of your cluster.

This would be speed up the ability to work fluidly with clusters rapidly.

2) De-clustering functionality

As is with coding, sometimes a cluster makes sense; sometimes it doesn't. Sometimes the wrong aspects of an operation have been clustered, and it makes sense to undo the entire thing. But when this happens, you have to copy-paste from within a cluster, and have to manually hook up all of the lines back together, which is a great annoyance.

It would help greatly to right-click on a cluster, select 'decluster', and have the cluster un-clustered, with all of the connections reconnected in their original position/location. By making the 'cluster' operation work both ways, I think this would also really enhance a cluster workflow.

This would also solve the problem of adding things into a cluster. Normally, you have to copy components, paste them into the cluster, and re-link them within, which is a simple operation, yet takes a minute or so. With this functionality, you'd be able to decluster, select the declustered components + new components, and cluster again -- quickly adding components/items to a cluster.

Thanks for hearing me out!

Best,

Dan

Replies to This Discussion

Permalink Reply by David Rutten on January 11, 2014 at 3:04am

Hi Dan,

posting requests here is fine, best place for it. I do have some questions:

but if the cluster takes a few seconds to execute, adding/removing clusters becomes pretty cumbersome.

Adding a variable input/output would also have to execute the clusters again, so I don't quite see where the gain is here. In fact if you open the cluster, make all the changes you want and then close it again, you'll only have to recalculate once, whereas adding 3 inputs via the ZUI would recalculate 3 times right away and once more after you've changed the cluster to hook up the new inputs.

This would be speed up the ability to work fluidly with clusters rapidly.

I still don't see it making a lot of difference, but I could well be missing something. What's wrong about this list of steps for doing it now:

Double click cluster.
Navigate to where you want to add new hooks.
Add hook (either from the toolbars, or by copy/pasting existing ones, or by double click search)
Connect hook to relevant parameter. This will cause a new intra-cluster solution which may take some time to complete.
Repeat 2+3+4 until satisfied.
Close and Save Cluster. This will cause a new extra-cluster solution which may take some time to complete.
Connect new inputs with relevant parameters in the parent document. Each new connection will cause a new solution, which may take some time to complete.

compared to this list of steps that you are suggesting:

Zoom in on cluster.
Click on the (+) symbols to add inputs. Each click will result in a new solution, which may take some time to complete.
Double click cluster.
Navigate to where the new input hooks were created (you don't know exactly where, so if the cluster is large, this may take some searching).
Probably move the hook to a more meaningful location.
Connect hook to relevant parameter. This will cause a new intra-cluster solution which may take some time to complete.
Repeat 4+5+6 until satisfied.
Close and Save Cluster. This will cause a new extra-cluster solution which may take some time to complete.
Connect new inputs with relevant parameters in the parent document. Each new connection will cause a new solution, which may take some time to complete.

Unclustering is indeed a useful feature. It used to exist I think back during the first cluster iteration. I suppose all the components to the right of the cluster would have to be moved further to the right to avoid overlapping components once the cluster has been exploded. But then it would also make sense to move components to the left when you make a cluster, so this could be reasonably two-way too.

David Rutten

david@mcneel.com

Permalink Reply by Dan Taeyoung on January 11, 2014 at 8:47am

Hi David,

Thanks for your response!

Adding a variable input/output would also have to execute the clusters again, so I don't quite see where the gain is here. In fact if you open the cluster, make all the changes you want and then close it again, you'll only have to recalculate once, whereas adding 3 inputs via the ZUI would recalculate 3 times right away and once more after you've changed the cluster to hook up the new inputs.

Does the cluster recalculate the entire solution, even though the new input hooks aren't connected to anything? Would it be possible to not recompute (not call ExpireSolution or its equivalent?) when an input parameter is added via the ZUI only? Could this be done by adding a flag on each input hook added by the ZUI, triggering the flag when the input hook is connected to a parameter, and recalculating the cluster only when the flag has been triggered?

Also, the current behavior, I think, is actually different. In order to work with the cluster, you need to see the geometry/data you're working with, so you have to enter the cluster, add the hooks, leave the cluster, connect the hooks to parameters, enter the cluster, play around in Grasshopper, exit the cluster:

Double click cluster.
Navigate to where you want to add new hooks.
Add hook (either from the toolbars, or by copy/pasting existing ones, or by double click search)
Close and Save Cluster. This will cause a new extra-cluster solution which may take some time to complete. (1 ECSOLUTION)
Connect new inputs with relevant parameters in the parent document.
Double click cluster.
Connect hook to relevant parameter. This will cause a new intra-cluster solution which may take some time to complete. (input * ICSOLUTION)
Repeat 7 until satisfied.
Close and Save Cluster. This will cause a new extra-cluster solution which may take some time to complete. (1 ECSOLUTION)

Which comes to: 2 extra-cluster solutions, and N intra-cluster solutions, where N is the number of new inputs. The cluster was opened and closed twice.

Zoom in on cluster.
Click on the (+) symbols to add inputs. Each input added via the ZUI doesn't recompute, since we know that the input hooks created this way aren't connected.
Connect new inputs with relevant parameters in the parent document. Also no new solutions.
Double click cluster.
Navigate to where the new input hooks were created (Perhaps aligned vertically, below the last-most input hook?)
Probably move the hook to a more meaningful location.
Connect hook to relevant parameter. This will cause a new intra-cluster solution which may take some time to complete. (input * ICSOLUTION)
Repeat 7 until satisfied.
Close and Save Cluster. This will cause a new extra-cluster solution which may take some time to complete. (1 ECSOLUTION)

Which comes to: 1 extra-cluster solutions, and N intra-cluster solutions, where N is the number of new inputs. PLUS, you only had to enter/exit the cluster once.

Thanks again, David!

Dan

Permalink Reply by David Rutten on January 12, 2014 at 1:34pm

Oh I see:

Also, the current behavior, I think, is actually different. In order to work with the cluster, you need to see the geometry/data you're working with, so you have to enter the cluster, add the hooks, leave the cluster, connect the hooks to parameters, enter the cluster, play around in Grasshopper, exit the cluster

The point is that you have to go through the process twice. First to add the hooks, then back out to connect the new inputs with existing data in the parent document, then back in again to create the new cluster logic now that you have data and can see what's going on. Yes, that is indeed a fairly significant extra step.

David Rutten

david@mcneel.com

RSS