Suirify lives on!

I still wish that GH would not grow paths when not needed.
As a behavioral option perhaps ?


I remember I became a lot more productive in Grasshopper by embracing the growing paths and not flattening or simplifying when they don’t happen to match what you expect, controlling the relative path growth when necessary by using the trim tree component.


I understand what you mean Vicente, and I embrace growing paths automatically when it makes sense.
Yet, I still don’t understand why it should be systematic, and I just hate those silly {0;0;0;0;0… for 3 reasons :
-When I need to merge data streams, they screw up the expected result, putting lists in different branches when they should really be merged.
-It makes the understanding of the actual tree structure difficult to read, even with the param viewer.
220626_IMG_Param Viewer

-And also, just for the same reason I like my green peas to follow a perfectly hexagonal pattern in my plate :slight_smile:
No seriously, keeping tree structures compact in their description helps to compare them and know whether they will properly work as inputs for a given component.

Moreover, I find that this branching frenzy is one of the big hurdles for a beginner, because it make the structure difficult to read, and itdoes induce the temptation to flatten things, or using the “old” simplify which was a recipe for disaster.

1 Like

The way I avoid those zeros is to keep in mind the extra paths that are not required vs the ones that are and surgically use the “trim tree” component to flatten only those, ideally immediately after the component generating them. This way if later the tree structure changes and more paths are added around the “surgical flattening”, everything will line up as its supposed to.


This exact workflow helped me solve numerous problems. +1

1 Like

Hi Richard, looks like you don’t mind useless branchings, huh ?

I doubt that you do that really all the time because you would be peppering “Trim tree” components everywhere.
To me, this is just wasted time, and it wouldn’t happen if this “auto-branching-no-matter-what” business could be toggled off.

you would be peppering “Trim tree” components everywhere

Correct, lots of trim tree components everywhere, at least a lot more than if you globally flattened or pruned branches. It was the only way to mange and keep very complex Grasshopper files maintainable.
Now my memory is not like it was in my 20s, and can’t keep in my head those complex branch structures, so I just mainly write code :stuck_out_tongue:

Sorry folks, but I can’t come up with a realistic scenario where this fake branching is necessary.
All I hear is people boasting how they can live with it, thanks to their great skills.
I’d be happy to be proven wrong though. At least, I would know why macheting my way through definitions is the lesser of two evils.


Maybe your approach to data trees is what’s incorrect and why you feel you need to “hack” your way through it. :wink:

I’m fine thanks.
Feel free to come up with a concrete example where, if the auto-branching behavior wasn’t there, things would fall apart.

Yeah… thought so.

I don’t feel the need for Suirify. I handle trees using Shift Paths components (pretty much the same as Trim Tree). I never Flatten (except for debugging purposes in some cases) and never Simplify because those operations break the tree structure.

Those branch paths that you mention are not useless or ”fake”. They originate from the underlying rules of the Data Tree handling. If you divide a curve {0} into 10 points, the resulting points have a path of {0;0}. This should not be trimmed to a list of points with a path of {0}, because then the definition does not work if you pass in multiple initial curves to divide.

I feel like I’m stating the obvious as others also have in this thread. Am I missing something in Suirify? I’ve never used it so I might not understand the behaviour.

Suirify is a great tool for beginners. It helped me a lot before I’ve learnt other tools to control the tree structure.
I don’t use it anymore but I appreciate it’s existence,

1 Like

Hi Tuomas,
Suirify is nothing more than a “Simplify” that will also transform a {0;0} to a {0} if that’s the only branch.
It isn’t much, but it saves a lot of trouble sometimes, and I’m happy that it’s become the standard behavior of “Simplify”, because it makes more practical sense.

Now as for the “fake” branching, I don’t think your example illustrates the real problem.
Here’s an example with both one curve and two curves.
Apart from the useless garland of “zeroes”, the tree structures are exactly the same with and without Suirify. (10.6 KB)

If you’re happy with machine-gunning “Shift path” components over your definitions all the time, that’s all good for you, but I would really appreciate a global toggle to switch that branching behavior off.
I know I never run in bizarre cases where that branching is useful, because I would have noticed.
You see, I also spend a lot of time trimming those un-necessary levels, so I would have noticed.
@DavidRutten, if you hear me…

Please fellows, understand that my request is not about having a systematic Suirify behavior at component output.
It’s about not adding branch levels systematically, which is completely different.


The problem I always had with this approach was the depth of my paths would sometimes change depending on whether I had a single input vs multiple inputs, for example, a single brep vs. a list of breps. So some of the trims wouldn’t have just been a trim, it would have been a trim with a dynamically varying trim depth depending on the depth of the paths in the input tree.


@osuire Just to add a voice to say how much I agree with @visose and I’d encourage you to try out the advice!

Yes - it does lead to lots of trim tree components (or path mappers are also a good option - they clearly show what they are doing). But it really the most consistent way to work with trees.

It should be systematic because then it is predictable and reliable.

My best advice is to have a clear meaning behind each level in a path and to label these on a parameter component. For example {gridx; gridY; storey} - this is really helping for others to understand the structure also.

I agree it isn’t ideal for beginners. The example I usually show is to set up a script with a single curve input and show the extra zero somewhere downstream in the graph. Then I change the input to a list of curves and show how that zero was telling us something - which input curve we are looking at.

Did you see my example ?
As you can see, each set of point remains neatly in a separate branch corresponding to the input curve.
No need to add an extra branching level.

If someone would provide a concrete example of a case where the extra branching level saves your but, I’d much appreciate.

1 Like