evaluate component breaking path names

Replies to This Discussion

Permalink Reply by David Rutten on September 22, 2012 at 6:24am

This is a result of the new data matching algorithm that was introduced in 0.9.0005. Since the input data to the Expression component consists of data trees which all have paths of only one number each:

• {0}
• {2}, {3}, {4}, ... , {42}, {46}
• {2}, {3}, {4}, ... , {42}, {46}

Under the new scheme, the overriding characteristic by which 'master parameters' are recognized is path length. All path lengths in this case are 1 and there is thus no definite master parameter. In the case of a tie the topmost parameter wins, which in this case is the expression string with a path of {0}.

I'm not saying this is how it should be, but it is not a bug as it does in fact behave the way it was designed to behave.

Earlier versions also took the number of paths into account when deciding on a master parameter. I removed this consideration as it resulted in sudden and -somewhat- unpredictable 'master parameter flips' due to natural manipulation of data. Under the new scheme, I tried to make it as unlikely as possible that a different parameter would become the master parameter when you drag a slider*.

A possible solution to this problem would be the ability to manually identify a master parameter. I am however hesitant to add UI for this as it is a very expert user kind of feature. 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

* If you manipulate paths directly in your document then all bets are off and there is no way for me to consistently pick a master parameter.

Permalink Reply by David Stasiuk on September 22, 2012 at 7:18am

aha..I so rarely think of the panel that goes into the Function input as a standard input...but of course.  Thanks!