Element Geometry component and depth of the branches

[Japhy]

if you really want to know…

Your Opinion on Tree Simplification Rules

Request for input. Tree simplification in GH2 behaves differently from GH1 (even differently from Suirify). There are three options for simplification; RemoveLeadingOverlaps, RemoveTrailingOverlaps, and RemoveAllOverlaps. In case this isn’t self-documenting, consider the following tree: \{0;0;0;1;0\} \{0;3;0;2;0\} \{0;8;0;3;0\} RemoveLeadingOverlaps simplifies this to: \{0;0;1;0\} \{3;0;2;0\} \{8;0;3;0\} RemoveTrailingOverlaps simplifies this to: \{0;0;0;1\} \{0;3;0;2\} \{0;8;0;3\} a…

Use the Suirify component where simplify doesn’t do the job.

WISH : "Match by branch paths" option in relevant components

Again, un-needed branching is very troubling to me. Suirify adresses the issue here, while “Simplify” doesn’t : [The Suirify nuance] Here’s what it does. It does more or less what I would like the components to do according to the title of this thread. Limits are made to be pushed back, aren’t they ? That’s what I do, and I find treesloth tools very useful to that end, but I could probably achieve the same with a bunch of GH components connected in a well-crafted manner. It would just…

Simplify option needs to get universal

OK, Let’s quit joking. I get why some components will graft the output, but the simplify option is there to prevent that when the grafting is not desired. Then it should also work when the input tree has a single path, period. I don’t care about the futile philosophical reasons ; I just see that it makes a complete mess of my definitions, and requires silly workarounds all over the place ! [Simplify%20in%20your%20face]