What's your largest Grasshopper script? [The Hall Of Shame]

But way more cleaner than your first picture :slight_smile:
Is that your „you can’t fire me“-Strategie?
Nobody else can use that file! :smiley:

Btw: I really like the result.

1 Like

It is always logical if it connects logically. GH could have “layers” so that one could stack logic and connect between them as a 3D sandwich. Then related logic would be both located and connected “nearby” each other.

// Rolf

1 Like

Well first of all we should not compare apples with oranges. Some people solve problems completely within Rhino and Grasshopper. And they can, because their problems allowing them to do this. Good examples are shown above.
In my field of work (automotive) there is a hardly anything I could fully automate. There is simply to much features missing, so I create solutions which support the traditional approach but doesn’t replace them. Not even close.
I also write my own tools, solving very common problems. So I made a whole surface toolset of features missing. On the other hand there is hardly any script where no custom solution is required.
I code for new features, I script to simplify gh definitions.
Component count gets often very big because most components don’t really do much. “List item”, “multiplication” etc … Often you can replace 2 or 3 components with one simple line of code.
I tend to create one custom components for 10-40 components. Not more, not less. If you do more you loose modularity, if you do less you don’t really have any benefit from it.

Regarding how to do a definition:
I personally distinguish between creational and defensive mind-set, which comes from programming. In creational mode I follow no rule of “good” practice nor I care about error,documentation, performance and extensibility. The thinking is: I don’t make any relevant mistakes, I just want to solve the problem, I don’t care if someone else don’t understand what I’m doing. Some people always stop working on it when the problem is solved, but this where the real work actually begins. Same for modelling. You don’t stop when finishing a model. You clean up, improve and simplify.
These problems getting solved in a second step, when being defensive. The thinking is: There is never a perfect definition.

6 Likes

So true. It’s not until you got something working that you actually start to understand the (full extent) of a problem. So a good approach is to “just do it”, and then, as you say, refine it.

If you also need to share a solution with others, then there’s the need for some strategy or structure that can be communicated. This is a weak spot in logical networks. Structure contaning very different levels of logical complexity, is in itself not “explanatory”. Grouping helps, but not even that is always enough.

Named relations (wire ends), for example, is still a missing important feature in GH. (two connections to the same component inport doesn’t always have the same meaning, and often the meaning isn’t clear even for a single connection).

Capturing a diagrams’ meaning and intent on multiple abstraction levels is tricky stuff, but adds real value if a definition is to be shared.

// Rolf

1 Like

The Kite Design script has been built up over time - and evolves as I need it.

The only ‘best practice’ I think I have picked up is to isolate subroutines as ‘pure functions’ and build these in a way that would allow them to be turned in clusters. I.E:

1/ Data in on the left, Data out on the right - no connections in or out of subroutine mid function.

2/ ALL data passed in and out via NAMED parameters (I generally I use Geo or Num types for this) - no wire attached to a function block is allowed a connection outside of its subroutine

3/ Group and label each subroutine so I know exactly what it does without needing to poke around.

I have no idea if this is the BEST way way of doing things - but it works for me and over time I’ve been able to amend/update/replace various subroutines without needing to trace/rewire 100s of connections.

Cheers

DK

2 Likes

If you to a lot of top down definitions you could try my wire hack :wink:

3 Likes

Cheers I’ll have a look tomorrow!

For me personally it would be cool if we could the way we can extend canvas with ALT+drag to extend it like “circle grow” ALT+ drag to increase radius

What’s the threshold for starting to use actual script components?

Mine used to look like that until i started using worksessions and maintain paths.

Capture

What does that mean in practical terms?

// Rolf

I am able to link various components (large AEC projects), query via attributes, path structure or whatnot. Generate geometries/attributes via small scripts, bake. Repeat.

The process used on Morpheus basically. It works, very well.

https://vimeo.com/203509846

3 Likes

nobody show @marcsyp this thread he’s built some doozies :smile:

I’ve watched the full video last night and this is very interesting approach. Might not fit very well into my needs but I really like the idea of keeping structure in very low level. This gives us much more flexibility in distributing specific parts to different nodes/instances doing different job (At least this is my understanding)
Personally I don’t like keeping any geometry in Rhino document (except final one) but for example using Firehopper could be a nice way to communicate and send data between nodes.

what it does?

this is actually a good size. Nothing to feel ashamed of! I agree on splitting different tasks/parts into separate files. This is somehow equivalent to Catias Product/Part structure. However the same a huge definition isn’t something to be proud of, I believe a project split into many multiple files isn’t necessary better. Its always a matter of balance, and as such the importance is on simplicity. I also believe, that instead of grouping or laying out in specific order it is much more important to document your process. This is difficult in Grasshopper (or in any other node-based editor), so before I did a lot of coding, I did a lot of canvas sketches, to visualise what a group is doing. It took ages, but was so easy for others. However since I code a lot, this became a bit obsolete.

How is that so? That sketching became obsolete. One would think that for grashopper less sketching is needed as you can practically visaulize everystep. While with coding you cant really see what is going on inside the script, why do you need less sketching then?

This is probably because there’s a conflict between (logical) Structure and Behavior (Flow of data).

It shouldn’t have to be a conflict, but since in GH we typically try to lay out a “flow” of data & processes, the logical structure (which holds the “meaning” of what is actually being done, and in part, how) is not explicitly clearified.

And often a logical network needs to be drawn in multiple different ways to convey different specific meanings (class diagrams for example are typically drawn in multiple versions, in the same model, in order to highlight specific “meanings” or aspects of a logical structure). And sometimes the structure itself (the actual wiring) holds meaning (I call that “implied logic”). Implied meaning often must be explain in natural language, unless it’s a simple and very typical pattern.

Multiple Versions
In short; Often multiple diagrams (using the same components or entities) highlighting parts or different aspects of a logical structure is required to document it so others also can understand what it means or does.

Different Types
Sometimes even different Types of diagrams are needed. For example, UML diagrams at the lowest level typically consist of #1 Class Diagrams and #2 Object Diagrams . But since the same classes (or objects) are used in different contexts, there’s also need for extended notation for specifying the different uses of a class. See example below:

Fig. 1 Classes to the left, wired instantiated Objects to the right (thus, essentially the same thing, but on different levels of abstraction). A/Top - no distinction between two different use of the same class (similar object), which is an address in this case., B/Bottom - using role names to clarify what use(s) a Class/Object is enroled in :

Rolenames can be useful in both directions. For example, looking from the Address class towards the Person class, the role names could have been employee and resident (multiplicity wasn’t explcitly specified here so singular (single link) implied).

// Rolf

3 Likes

Because if you script it is much easier to comment. for 100 lines of code its never wrong writing 100 comments. Who writes 100 lines of comments on 100 gh components? Never seen that. So I used to draw the process.
Of course you need to learn to comment the right way, saying what it does and why its there; not what it is.

Furthermore you get rid of all the tree management, basically writting scripts very procedual. This, at least for me, simplifies understanding the underlying logic much easier. When doing scripts I also like to create some sort of generic debug output parameter, which allows me to output temporary steps.

But what makes a gh definition hard to maintain? In my experience it is wire spaghetti and components for data control. A list item component takes the same visual space like for instance the boolean union component. So you get very easily distracted from the intention of joining two breps, if you need 3 components beforehand to pass in the data…

Well it doesn‘t mean its still nice to have some well made pictogramms

3 Likes

Haha – okay Andrew, I’ll take the bait.

Here is what I’m working on right now. As of today, 23,226 components. This is a full-featured conceptual design application (for architecture) with suppressed Grasshopper, Full Human UI, Onboarding, Two-Way binding with the Rhino interface, many control flow hacks, custom data model, over 500 telepathy namespace entries, clickable meshes, file/data/model exports, etc.

Our GH template autoscans our definitions to update the counts + group colors, and it takes over 3 seconds to get through all the components on the canvas.

I would need 4 monitors just to see it all at the same time (I blew through min zoom a LONG time ago). :smiley: I’m right in the middle of a feature addition and haven’t cleaned up my layout yet, particularly on the right – warning, not for the faint of heart:

12 Likes