algorithmic modeling for Rhino
Since "Grasshopper™ is a visual programming language" is there any style guide like PEP 8 for Python? Like when to use groups, clusters, hidden cables, duplicate things etc? And if not, are there still any tutorials that help me understanding how to organize my definitions in a proper way?
It's a good question, but not one I can point you in the direction of a single answer.
I think if everyone contributes what they do here then we can maybe come up with a guide as to best practices.
I'll post mine in a bit
Create a Template File.
I like to have a template that gets opened each time I create a new document. That way I can have my "signature" already there. Also you can set preview settings like "high quality" or "wireframe preview" for example that will always be there by default.
To set your template go to File > Preferences > Files > Template File
Collect all User defined Variables and Referenced Geometry in one place:
I typically have every possible "variable" component in the top left hand corner to allow a "user" to only have to focus on one part of the canvas when making changes.
The outputs of the User group are always "TEXT" with a meaningful variable name. I then copy these to the locations on the canvas where they will be used and connected by Hidden wires.
I know this is an old thread, but:
From a relative newbie to Grasshopper - how do I make the tags that your input parameters are fed into?
Solved my own question. It's just a parameter of the same type as its input, with the display setting set to "Always draw name". Boy, do I feel slow!
As a matter of choice I have:
Draw Full Names Un-ticked
Preview Mesh Settings - High Quality
Bump Preview Un-ticked
Point Flavour Cross
Preview Mesh Edges Un-ticked
Construct Point as XYZ
Deconstruct Point as pComp (old school)
I like to have the create a line as Line so that it defaults to this instead of the Param Line
Numerous others I cannot think of at the moment
I think this post is great.
Very nice replies, Danny.
A dead thread, but I just wanted to say:
This is actually spot on how I teach students (as a student who runs workshops) to organize their documents and how I organize all mine. How convergent.
Modules (subroutines), headers, a control panel, faint wires between modules and hidden wires to jump around. Perfect. Helps so much with reading the overall flow of a script.
I'd be very curious to see other users' versions of a highly curated definition since one thing I find in GH is that while poorly written code is often manageable, a poorly organized gh document can be absolute hell.