One vs two or more

Replies to This Discussion

Permalink Reply by Vongsawat Wongkijjalerd on March 8, 2017 at 1:49am

but.. Shift List works the same for any number of items and any number of branches..

..do you instead mean Shift Paths? and are instead talking about branches as opposed to entry items?..

In which case its working exactly according to its logic and how trees are formulated in gh. I'd prefer it if "one" was special in which case Shift Paths would work as usual for any number of branches, but do nothing if there was only "one" path.

If I'm guessing your use-case correctly, try using Trim Tree

(alternatively, if I've completely misconstrued your issue, sorry!)

Permalink Reply by Olivier Suire on March 8, 2017 at 8:42am

Yes, I meant "Shift Paths", sorry.

Permalink Reply by Daniel González Abalde on March 8, 2017 at 2:51am

GH is not responsive to 100% with data structures. This for me is a serious problem, especially because it limits the ability of plugins using UserObjects. It can be solved using more components, making different ways for different structures, but this is very dirty. See this:
http://www.grasshopper3d.com/forum/topics/allow-more-easily-respons...

The [Shift List] component fails when you try to offset more than the number of indexes the path has. This should have a parameter to choose if when this happens, return the most offseted valid branch. But this component is an exception. Right now I do not remember anyone else who has a similar problem. There may be one or two more, but not many others.

The inputs and outputs have access types ("as List", "as Tree", or item) which appears after the name of the parameter when you put the cursor on it. This specifies what the component is designed for, but it is not exclusive, so you can use other data structures but always taking into account the accesses and above all, the structure that you want to obtain. For example, if you give a list of N elements to an input with access item, that component will run N times before continuing downstream execution. If you give a tree with N branches to a parameter with list access, that component will run N times.

That said, actually gh always works with branches. An item or a list, always has a path, usually the {0}, that is, everything is within a branch always, although to avoid ambiguities and failures in understanding this is not taken into account. So I do not think it's a quantity problem, but that gh is meant to work node-to-node, and it does not have a way of setting the access types for the entire definition as a whole. 

Permalink Reply by Daniel González Abalde on March 8, 2017 at 8:48am

The [Shift List] component

The [Shift Paths] component*
:V

Permalink Reply by David Rutten on March 8, 2017 at 5:38am

I hope that V2 brings a simple solution to this.

Me too. Trees were added about halfway during GH1 development and they have never shed that experimental whiff. nobody really knew early on what sort of operations would be useful which is why we've ended up with too many components that kinda sorta do the same thing but not quite, and often don't do it well.

Permalink Reply by Olivier Suire on March 9, 2017 at 2:44am

I was pondering the idea of systematically adding a "bogus" entry item to make sure that there will always be at least two entry objects...

How do you guys deal with this generally ?

Permalink Reply by Julian Buhagiar on March 9, 2017 at 4:28am

I avoid Shift paths, I tend to systematically decompose the branches, recompose them and use find replace branches which I've found far more robust than both graph mapper and shift path.

Permalink Reply by Olivier Suire on March 9, 2017 at 7:02am

Hi Julian,

This looks really smart.

I'll definitely give it a try.

Cheers,

Permalink Reply by Julian Buhagiar on March 9, 2017 at 10:09am

Just improved it (firstly I forgot to connect a pipe) and secondly I've made it mimic some of the inbuilt breakable GH components including shift. and added some additional features

I particularly find the path mapper useful when you want to keep the tree alive, but make the leaves the dominant branch somewhere in the dataflow. Its like flip matrix in some ways but can handle the multiple dimensions.

Whilst its all in one Cluster, I would recommend probably separating deleting the parts of the cluster you don't need for any particular GH definition you're working on. I just keep it as one so that I don't end up with loads of icons in the ribbon.

Attachments:

• TreeSurgeon.gh, 31 KB

Permalink Reply by Vongsawat Wongkijjalerd on March 9, 2017 at 11:24pm

[Trim Tree] is a simple alternative. At most I'd need to Simplify to make sure the outermost branches being trimmed aren't singular/meaningless branches. 

Permalink Reply by ng5 Alex on March 9, 2017 at 11:32am

I think shift safely from tree sloth plugin might come handy for this too.

best

alex