Grasshopper

algorithmic modeling for Rhino

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.

Views: 492

Reply to This

Replies to This Discussion

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 ...

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.

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.

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.

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 ?

Than please explain the logic behind this:

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.

Why then does the following VB Code work?

x.SimplifyPaths()
A = x

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.

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:

This is an example of data which requires two indices in the output to keep stuff disentangled.

Here's what I'd like :

This issue is probably THE reason people drop Grasshopper past the initial amazement, because they get tangled up in uselessly convoluted data trees.

RSS

Translate

Search Grasshopper

Photos

  • Add Photos
  • View All

© 2017   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service