Feature Improvement Request

So there is likely a very good reason that on any of the list objects, the output adds a redundant branch to the leaf side of the data tree.

Many other objects add redundant branches to the trunk side of the data tree. I'm blind to the utility of adding redundant branches anywhere to a nice, clean, well organized data tree; but at least there is the 'Simplify Tree' object to take care of the redundant branches on the trunk side. It doesn't, however, eliminate redundant branches on the leaf side of a data tree.

Feature Request: Make the 'Simplify Tree' eliminate all redundant branches.

A more significant feature request that I'd like see would be to optimize all the GH objects that introduce redundant branches by their operations so that they don't do that. In my experience, dealing with the redundance unnecessarily hampers the 'work flow' and clutters the work space. However, it's probable that the redundancy is introduced for some good reason that I'm not aware of. If that is indeed true, I would appreciate if the community would school me on why the redundancy is introduced and how you're using it to your advantage.

I am aware of how to eliminate these pesky trailing redundant branches via the 'Replace Branches' object. It's just that 'List' objects are used so often, that it's rather annoying to have to doctor up the data tree every time with all that's required for 'Replace Branches' to work correctly. For the time being, this is a great redundancy patch for me: http://www.parametricmodel.com/PartialFlatten/25.html

But it would be really nice to not have to be concerned about how many branches need to be cut off. 'Simplify Tree' would just be great if it performed on both sides of a data tree.

Replies to This Discussion

Permalink Reply by Mateusz Zwierzycki on February 24, 2011 at 5:45pm

what with path mapper ?

Permalink Reply by Andrew Heumann on February 25, 2011 at 12:49am

the path mapper, as useful as it is, is not always a truly "parametric" object, because it will fail to work if the data structure entering it changes upstream. There had been some talk about the introduction of wildcards into the lexical mapping of the path mapper, which might serve to alleviate this a bit.

Gabe, I am glad the partial flatten component has come in handy for you. Attached is another cluster I put together that will simplify from both sides, removing all path index levels that are 0 for every item in the input data. It should work as long as all input paths are of the same length (i.e. no data containing both {0;0;3} and {0;3;2;1;0;0})

I am with you that something like this ought to be incorporated into grasshopper directly, unless I am missing some already-present way to do the same thing more simply. If there is a reason to leave the trailing 0s on "simplify tree," perhaps another component that can trim them from both sides would be a useful addition to the tree management utilities.

Attachments:

Simplify_All.ghx, 585 KB

Permalink Reply by Gabe Krause on February 25, 2011 at 9:29am

Andrew, clusters like that challenge my perceptions of aesthetic beauty. It's perfect!

I am still curious about the tendency for GH objects to introduce redundant branches. The Data Tree paradigm is such a significant development, and Grasshopper is generally so well though out that it's hard for me to believe that the redundancy wasn't introduced for some organizational purpose. Is anybody privy to it's purpose? Or is it just a result of some programming shortcuts?

RSS