WISH : no trailing zero option

I still haven't figured out why some components insist on adding a trailing zero in the output tree structure while others just mind their own business.

At first, it led me to using the "Simplify" option like crazy, which had the adverse effect of screwing up my definitions when upstream data had varying levels of branching.

(Thanks to Andrew Hewman for pointing out that "Simplify" was an "absolute" operator, and that I should stick to "relative" operators to have robust definitions).

I use the path mapper to get rid of the extra branching, but I'm sure that this might also spell "trouble" if the upstream tree structure changes.

So I think it would be nice to have some kind of toggle inside the component to block this nasty branching mania.

Replies to This Discussion

Permalink Reply by Richard Schaffranek on August 29, 2017 at 2:25am

Yes please, this is anyoing as hell:

Also sometimes flatten / simplify doesn't remove doese trailing 0 when it is a single list...

I always have to make it via a vb component and have to use simplifyPath there ...

Permalink Reply by David Rutten on August 29, 2017 at 3:40am

At first, it led me to using the "Simplify" option like crazy, which had the adverse effect of screwing up my definitions when upstream data had varying levels of branching.

And that is why these zeroes are added.

Permalink Reply by Olivier Suire on August 29, 2017 at 4:27am

Hi David,

In the example, the output of "Deconstruct Brep" will always reflect the branching of the input.

I don't need/want an extra branching to be added.

Other components will not do this, so when you bring together the outputs of those who do and those who don't, well... it doesn't match.

As Richard points out, there's also those pesky trailing zeroes in single lists.

I rather stay in control rather than having some obscure wiseness forced upon me.

Permalink Reply by David Rutten on August 29, 2017 at 7:28am

But the component doesn't know that you will never provide it with inputs that contain more than one brep per list. It has to take into account that it could one day happen, and when that day comes it would cause the output of the component to suddenly have a different number of elements in each path. The behaviour is designed so that the number of elements in each tree path doesn't grow or shrink when the input data changes. The only way to make this consistent, is to add these zeroes more often than strictly needed.

I hope to make it easier to revert to simpler paths in GH2. I myself am bothered by the proliferation of indices, but I doubt it will change for GH1.

Permalink Reply by Olivier Suire on August 29, 2017 at 8:00am

Duh... whether I have one or multiple inputs in the following example, I don't need the extra branching, and the downstream components will be just fine.

I can't think of a time when this was useful to me ; a concrete example would be nice.

Until GH2 comes, what would be the ideal VB script or set of components to cancel this, for dummies like me who feel they will be better off with easy-to understand paths structures ?

Permalink Reply by Richard Schaffranek on August 29, 2017 at 8:01am

Than please explain the logic behind this:

Permalink Reply by David Rutten on August 29, 2017 at 10:38am

Simplify works by removing all those elements that all paths have in common. If you only have one path, 'having in common' is meaningless, which is why Simplify doesn't work on trees containing only one path.

Permalink Reply by Richard Schaffranek on August 29, 2017 at 10:51am

Why then does the following VB Code work?

x.SimplifyPaths()
A = x

Permalink Reply by David Rutten on August 29, 2017 at 11:14am

Because that method was written after I came up with initial definition for Simplify. The entire DataTree class was a fairly late addition to Grasshopper. Before it, script components couldn't deal with trees at all.

When I wrote DataTree is was obvious that the earlier definition (listed above) was annoyingly inconsistent exactly in this case, which is why DataTree.Simplify operates on a newer definition which also handles singular paths. However, I could no longer change the old Simplify behaviour on each parameter because that would break existing files that relied on it working the way it did.

Permalink Reply by Richard Schaffranek on August 29, 2017 at 11:29am

Okay that explains why but:

How can you get rit of the indices in order to merge e.g. two lists. Maybe you can have a look at the attached file. The old VB defintion seams to make so much more sence than the "new" definition at least in these case which I am having where ofthen...

Attachments: