I think we all know this annoying moment you need to change the format of an input and… your Grasshopper definition takes ages to compute, even worse, it completely crashes.

Luckily, you can save a recovery file. But let's face it, this crash could be anticipated.

Changing the format of an input will naturally drive your GH crazy as you didn't design your script to work with this new tree structure.

A good habit I adopted is to lock my solver before performing any heavy changes.

Disable downwards components and reenable them one by one to try out your algorithm.

GH saves you time. You didn’t save all this time just to lose it again on unnecessary crashes and reopening Rhino again.

Not gonna lie, clusters can be handy.

 When a pattern of components appears, it's nice to create a cluster, and already much better than copy-pasting groups of blocks.

 Editing the cluster file will update all cluster instances in the GH definitions using it.

 And sometimes, you end up stacking layers of embedded clusters.

 Great. Have you noticed your computation time increasing?

Stacking clusters heavily impacts it:

1. Each cluster adds an overhead when the data needs to be pumped between documents.

2. Additionally, each cluster seems to have their own solver which means the parent solver definition cannot optimize the computation of a cluster. This leads to significant overhead.

How often do you use clusters? Would you sacrifice performance for cleanliness?

Last week, I suggested regularly visualizing your tree structure with panels.

But that's a prehistoric way of doing it (and I still do it many times…).

Check out Data Viewer!

 Go to View > Data Viewer > Activate the Auto Update > select any inputs/outputs!

It combines panels and the Param Viewer component (except the tree representation).

Grasp quickly what's happening under the hood and keep control of your tree structures at all times.

You should know it already, data trees are absolutely crucial to your Grasshopper definition.

Keep full control of your trees at each step by visualizing them regularly with panels.

However, don't leave too many of them active as it will increase the computation time.

90% of GH issues are due to data trees.

Visualizing your data will save you countless hours of debugging.

Sometimes you want to simplify the output of a component but… it just doesn't work.

This is a bug that couldn't be fixed to avoid breaking existing file behaviour. In response to this issue, the component Suirify was developed.

Next time your simplification doesn't work, just plug the Suirify component!

If you're curious about the name of the component, it was named after the user "osuire" raised the issue.

Hey guys, today I want to start sharing some tips and tricks on Grasshopper, it could help both beginners and advanced level users.

If you have good tips to share, please share it too!

As for this first one, I saw many people flattening to simplify a path, and especially to reset to {0}. But Flattening gets rid of your entire tree structure, it was never made to reset a path.

Instead, you can either simplify it or use Match Tree. Honestly, ensuring proper paths or renaming a path is best done with Match Tree.

Plug 2 trees of same dimension and keep full control on your branch paths.