Path renumbering

In participating in another discussion about path and data management, I've come across something that seems odd to me...it appears that whenever a simplified, singly indexed path structure is fed into any of the list components, the paths are automatically renumbered. If, however, there is even one additional path index (even if they match throughout the tree), then the path structure can be retained. Is this deliberate? I guess I don't quite understand the logic of this setup:

Replies to This Discussion

Permalink Reply by David Rutten on March 22, 2013 at 5:51am

I can explain why it's happening, the code was intended to work this way, though I concede it doesn't make a lot of sense in this case. It's all to do with the detection of the master parameter. The MP is the component input parameter which is deemed most relevant and is therefore used as the mould for creating output data paths.

The logic of selecting which input is the MP is as follows:

Parameters with Tree access are never MPs, unless all inputs have Tree access, in which case the topmost one wins.
The longest path length in each parameter is found and it serves as an indication of the complexity of the parameter. The more complex a parameter, the more likely it is that it's important.
List parameters are treated as slightly less important than Item parameters in case they have identical complexity.

That's all there's to it. {0;0}{0;2} wins because it is has a maximum path length of 2 whereas the i and w inputs only have a maximum path length of 1. However by simplifying the data you end up with maximum path length of 1 {0}{2}, and since the L inputs have List access it loses out in this case.

I'm happy to make adjustments to the logic, but they need to be good. Changing this code will likely change the way a lot of files already work and if people rely on it working in a specific way we'll break those files, which is something to be avoided at almost any cost. So unless the proposed modification is clearly an improvement, I don't want to change this logic.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by David Stasiuk on March 22, 2013 at 6:30am

Fair enough: the singly-indexed path loses in the Octagon. Yes, certainly changing this behavior would create breakage in many a definition, so I wouldn't advocate for it. Maybe as a means to deal with it an append/prepend path component could be added?

I know that I very heavily simplify my data paths (being able to do it on the inputs and outputs of components is really such an incredibly useful option) in order to more easily manage them in large definitions. I also try to stay away from using the path mapper...not so much because I don't like it, but because often with different counts of geometries/applications of a definition, I'll just have different numbers of paths in each instance, and having to re-code the path mapper gets annoying in such cases...so as a result I rely very heavily shifting paths, which is great for maintaining relativity in structure. Having the ability to append/prepend would ensure that I could coach my data paths to always win in the Octagon...It's exactly this kind of component that I started Tree Sloth for, so I'll just plan on adding it there.

Permalink Reply by David Rutten on March 22, 2013 at 7:49am

An additional rule that may make sense would be:

If the longest path length in all inputs is 1 (i.e. minimum complexity) then start favouring parameters that have wires coming in, even if they are list or tree parameters.

I think it probably wouldn't cause much breakage because it is a rare case and it does make intuitive sense. Another thing which I've been thinking about is the ability to manually override the master parameter. It would obviously be a very expert user function, but it wouldn't be difficult to implement and it wouldn't break anything.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by David Rutten on March 22, 2013 at 9:15am

I added one rule:

If a parameter only has a single path and that path = {0} then consider the parameter to be empty. Basically it contains no information we couldn't create from scratch ourselves anyway so don't allow it to trump any other parameters.

It certainly makes this particular case more obvious, but it is a breaking change. However I feel it makes a lot of sense so I think I'll leave it in for 0.9.0015

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by David Stasiuk on March 22, 2013 at 9:47am

sweet!

Permalink Reply by Thomas J. Mrokon on March 22, 2013 at 9:48am

that would save a lot of path mapping....

Permalink Reply by Jesus Galvez on March 22, 2013 at 1:14pm

Hello David,

could you further clarify point number 1. Thanks again.

Permalink Reply by David Rutten on March 22, 2013 at 3:28pm

When an input has Tree access, it is not iterated over. All the data in the entire parameter is always used every single time. If a component only runs once per solution that is not a problem, but if a component runs more than once I have to make sure the output doesn't all end up in a single list (unless of course it's meant to up that way).

Basically whenever I need to start writing output data to a different list I need to know what path to associate with that list. I can easily dream up unique paths but it makes more sense to use the existing paths from the inputs. In order to recycle paths from inputs I need paths that actually differ every now and again and as we've already established trees never differ because they are always consumed whole.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Jesus Galvez on March 22, 2013 at 4:44pm

Ok thanks David. Is this going in the FAQ section?

Permalink Reply by David Rutten on March 23, 2013 at 5:16am

Probably should. It's an important topic, but very hard to explain.

David Rutten

david@mcneel.com

Poprad, Slovakia

RSS