Clusters

Clusters in Grasshopper 0.9.0005

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 clustera 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.

Note:

• Clusters can not yet be exploded. This feature will be added someday soon.
• Clusters do not like to have Text Panels as input or output objects. I do not know why yet, but I'm on the case.

--

David Rutten

david@mcneel.com

Poprad, Slovakia