algorithmic modeling for Rhino

Clusters in Grasshopper 0.9+

Clusters have been rewritten from scratch (again), though this time there are fewer visible changes. Note that clusters created with Grasshopper 0.8.0066 and earlier are not the same objects as clusters created with 0.9+. They can co-exist but all the improvements only pertain to clusters made with 0.9+.

The three basic features that were missing before are: referencing, entanglement and editing. It is now possible to have a cluster which references a file on the disk. When that file is modified, the cluster can be updated. However clusters maintains a copy of the reference file at all times, so it's possible to retain cluster functionality even though the file has changed. It's possible to reference *.gh/*.ghx files, but here is a new cluster file format called *.ghcluster which also stores additional cluster information such as author details, passwords and it is partially encrypted when a password has been defined.

When a cluster is copied within a single document, the two instances of the cluster will be entangled. Whenever you change one of them, it will also affect the other. Entanglement does not work across file boundaries though, so clusters which have been copied to different gh/ghx files -even if that file is still loaded- will not be affected by a change. The logic behind cluster-entanglement is as follows:

  • Every cluster has an ID. This ID is created randomly whenever a new cluster is made from scratch.
  • Whenever a cluster is saved to a file, the ID is also stored in that file, so IDs are retained during save/open and copy/paste.
  • Whenever a cluster is copied, the copy will inherit the same ID.
  • When a cluster is modified, it will also modify all entangled clusters in the same document that have the same ID. Then, all these clusters will be assigned a new random ID (but the same one for all of them). This way there is no conflict when an unmodified instance of a cluster is pasted back into a document.

Clusters can now be password protected. Passwords do not prevent a cluster from being used, only from being changed or opened. Protection is about as solid as I can make it given the circumstances of a non-obfuscated Grasshopper.dll and the necessity to store password hashes in the same file as the cluster object. The only way your password can become compromised is via a dictionary attack. It is easier however for an informed programmer to steal the cluster document. It is not possible to protect against this because Grasshopper always needs to able to decrypt a cluster whenever a file is opened. Passwords are always assigned to all the instances of a particular cluster in the same file.

When a cluster is 'opened up', a new document will be loaded into the canvas. This document knows it came from a cluster and the Grasshopper main menu will reflect this as well. The cluster input hook objects in these files will be filled up with the data from the original cluster object, to at least provide a partial preview of changes being made. When such a subsidiary document is saved, the original cluster will be updated and the file containing the original cluster will be loaded back into the canvas. When a cluster document is being edited, there will be a cluster icon on the canvas that provides some useful features.

There is no autosave for cluster editing, it is impossible to implement this unless I completely rewrite the way autosave works and the way clusters are (de)serialized.

Since it is now possible that two or more documents are associated with each other (I.e. the document which contains the original cluster object and the document which is used to edit the cluster) the close/save logic is a lot more complex than it used to be pre-0.9. When you close a document, all subsidiary documents will also be closed. You will be asked for confirmation if one of those subsidiaries contains unsaved changes. If you save a document, all subsidiary documents will also be saved.


You need to be a member of Grasshopper to add comments!

Join Grasshopper

Comment by ismail on November 30, 2013 at 3:35am

I need this add on

Comment by Jonathan Sheridan on September 16, 2012 at 11:54pm

Is there a reason why the process of Clustering is irreversible? It makes using them very much more difficult. 

Editing and updating clusters might now be easy and accessible - however adding and changing anything to do with inputs and outputs makes development of the definitions within the cluster very difficult. One can't visualise easily where external links go and reconnecting to other functions becomes more complex. Meaning; one is wise to leave clustering until after the definition is complete. Which ultimately makes editing in light of feedback from others in a definitions evolution more difficult, i.e. a number of people developing a definition that use clusters, or in working on a cluster with a password that clients might have put external notes onto, could be better designed if the author could explode the cluster to return to original state and make these developments un hindered with levels and connecting nodes. Am I missing a key piece of functionality in GH Clusters or are we all?

Comment by Jonathan Sheridan on August 31, 2012 at 6:41am

How do you explode the items back out of a cluster?

© 2019   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service