…since you can use “Split tree” instead ?
Isn’t that redundant ?
They have different uses. Tree Branch is for getting the specific branch of a not flat tree via branch address. Split Tree is for splitting trees based on custom mask patterns.
1 Like
Hi Michael,
I know that.
But if you didn’t have “Tree branch”, you could still acheive the same result with “Split tree”, thus the redundancy.
Best,
Tree Branch as far as I know is just a much older component, so even with redundancy I think a lot of people just got used to it so it stayed (I surely use it much more often than split tree) plus for that task of just getting a branch I think it is more intuitive. Split Tree to me is more pro level in syntax. Redundancy is just a thing that happens in software.
We are touching a sensitive subject : how the opacity of tree management deters a lot of people who are initially fascinated by the Grasshopper concept.
Sure : when you use the “Tree branch” component for the first time and understand what it does, you feel like Albert Einstein.
But the real power lies in the use of path masks, yet there’s really not much in the way of helping the user get a grasp of how they work.
Heck ! There isn’t even an example or explanation of the path mask syntax in the “Help” section of that component !
The only place I found a useful explanation is in an old 2013 post from David.
In short , I think we only need the powerful components, but with good documentation.
At least, I know it would have helped me immensely while I was crossing the “data tree befuddlement desert”.
1 Like
Maybe in GH2? For now I think from what I see it is hard to get rid of commonly used components. Gonna break a lot of definitions (tree Branch is used a lot) and probably would get tons of hate mail. 
Speaking of GH2… I’ve seen a bunch of sexy UI stuff, a sexy color picker and all, but is there anything tree-related that we could comment on ?
That’s what I’m really interested in.
Only David Rutten knows
There’s lots of redundancy indeed, especially in the list and tree sections. A more unified and trimmed down set of components is the goal for GH2, in all the categories, not just data management.
GH1 went from allowing a single value per parameter, to allowing a list of values, to a list of values including nulls, to datatrees within its lifetime. Some of the cruft has been excised but plenty remains, caking the surface in a scabby layer of oxidised feature-creep. And not just the surface, there’s oodles of obsolete methods and types left in the code as well.
1 Like
I holiday there often!
1 Like
I peed my pants laughing, David !
Well, I’ll just add that this is the best crufty, scabby and oxidized tool I’ve ever used.
GH2 promises to be a “Wall-E ->EVA” kind of upgrade … will it be conceivable to salvage old definitions ?
That is very much the question. The less overlap there is between components the harder that will get. And since the SDK is completely different, all plug-ins will have to be updated as well.
That is very much the question. The less overlap there is between components the harder that will get
Meh… fine with me.
I don’t like stagnating software… Speaking of Rhino, don’t you think you ought to make your own CAD plugin for Grasshopper at some point to get things really rocking ?
