Branches

Replies to This Discussion

Permalink Reply by Marios Tsiliakos on November 12, 2012 at 7:11am

Hi Jon,

I have also posted a similar wish/question on data tree management in this discussion. I was looking into "from scratch" definition of branches rather than a dynamic/parametric approach like yours, which would actually cover my end of the story too.

The behavior on the first example indeed seems bizarre. 

+1 for that.

Best,

M.

Permalink Reply by Andrew Heumann on November 12, 2012 at 8:04am

I agree that the behavior in the first concat component seems a bit odd; I would expect it to preserve the tree data. What makes it even stranger is that if you flip your A and B inputs, it DOES preserve the paths, leading me to believe this is some kind of bug. 

I'd also like to point you toward my "tree frog" path tools (rename pending) which might aid in this situation. In particular, given the two non-matching path structures you have (0-10) and (11-20), you can use the "Match Paths" component to coerce the one to follow the structure of the other. In general you can also use "Assign paths" to assign an arbitrary, user-generated path structure to any set of data. 

There is also a component in the same toolset which does something very similar to your script, with the added functionality of producing a copy of each path for each data item (so a tree with four items in a particular branch would get 4 identical copies of that branch path in the output.) Not sure if that's useful to you (especially since you've already written the script you wanted), but maybe it is. 

If you wanted to accomplish all the same with native components, I believe it is possible but a little clunky. See attached for a native example.

Attachments:

• 121111extractpathwithpath.gh, 8 KB

Permalink Reply by David Rutten on November 22, 2012 at 1:36pm

...leading me to believe this is some kind of bug. 

Actually no, it is working the way I designed it to work, so it's an arguable design flaw rather than a bug. The concatenate component is provided with two data trees, a small one containing only a single branch {0} and a larger one containing 10 branches {10} -> {19}. The output data of a component depends almost exclusively on the determination of the master parameter. The master parameter is considered to be the guiding light when it comes to cooking up output data tree paths. This master parameter is determined as follows (at least under the current logic):

• If there is only a single input, that one obviously is the MP.
• If there is more than one input, then Tree access parameters are ignored, i.e. Tree inputs are never MPs unless there is absolutely no other choice available.
• If there is more than one input, the one with the longest paths becomes the MP, in the example posted above, both parameter have equally long paths. Note that the amount of paths is no longer considered to be a good indicator, and for good reasons as it turns the detection of MPs into an unstable business.
• If all inputs have paths of the same length then Item parameters win over List parameters. Again, in the example Jon posted all parameters have the same access level.
• If after all this there are still several possibilities, then the top-most one wins. Which is why if you flip the inputs it suddenly starts working as you expect it to work.

Changing the selection of MPs is a dangerous business as it may very well break existing files that rely on a specific data tree layout. That being said, if a significantly better algorithm is proposed I'm happy to make this change. Do note that the algorithm cannot depend on the number of branches in a data tree. This is how it used to work and it resulted in some very unpredictable behaviour as the number of branches often depends on specific inputs and can therefore easily change when -say- a slider is dragged. The detection of MPs should be stable enough to not depend on something as volatile as that.

A possible (non-breaking) change that could fix these issues is to add GUI for manually picking master parameters. This is however a very (very) expert user level feature so it would be nice if we could improve the default behaviour first.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Jon Mirtschin on November 23, 2012 at 12:31am

Thanks for the explanation David, it's insight that might help.

I can see if I graft the second data it's closer to the branch retention that I was seeking.

In architecture projects branches can be a useful way of allocating "grids" or other aggregations of data (such as stories). Some data might be dispatched and aggregated downstream so the path retention is important. Of course adding a data matching component works, but it does add up to additional components (previously not necessary) that magnifies on a large definition.

I personally still think a {0} path with single item might be considered a special case. I understand it might break existing definitions (not ideal), but this isn't without precedent (I've seen plenty of 0.8 files needing path alteration to work in 0.9). My 2c

Permalink Reply by David Rutten on November 23, 2012 at 2:22am

It's actually not a bad idea to special case {0} paths, though even that might cause sudden discontinuities in certain cases. I'll fiddle around with it, see if it solves more than it breaks.

--

David Rutten

david@mcneel.com

Poprad, Slovakia