Parameter Layouts And Evaluators

[hoknamahn]

Any ideas how to make evaluation of parameters more flexible (or even automated)? Now evaluation of any parameter is dependent on position of that parameter in the parameter list. And if order was changed you have to change the number inside evaluator which is not cool especially if you have lots of parameters and nested switchers. So maybe there is a solution which allows to change layout without a pain?

[sibarrick]

Maybe I'm misunderstanding you, but can't you just use the name of the parameter instead of the index.

[hoknamahn]

Maybe I'm misunderstanding you, but can't you just use the name of the parameter instead of the index.

Hi Simon,

I'm talking about this

float	BIRTH(float t)		{ return evalFloat(2, 0, t); }

Where 2 is the index of parameter in the template list. So if you insert something before that parameter into template list you should change 2 to 3 and so on.

[sibarrick]

That's want I thought, just replace the 2 with the name of the parameter.

[hoknamahn]

Brilliant Simon What for we need a t parameter? I don't see comments related to it.

[Infernalspawn]

Brilliant Simon What for we need a t parameter? I don't see comments related to it.

t is the time, when a parameter is animatable, you might need it

[hoknamahn]

t is the time, when a parameter is animatable, you might need it

Hummm. Not sure that I understand... Which role play the t inside evaluator? What if parameter was described as PRM_FLT_J but t is constant say 0?

[sibarrick]

If the t isn't relevant it won't get used.

If I have a parameter that isn't animatible I just set it to 0, otherwise generally you set it to the current time, but you can of course evaluate the parameter at any point in time you like.

[hoknamahn]

If the t isn't relevant it won't get used.

If I have a parameter that isn't animatible I just set it to 0, otherwise generally you set it to the current time, but you can of course evaluate the parameter at any point in time you like.

Arhhh. I see. Some kind of chf()?

[edward]

I would discourage of old practice of sending a time value of 0 to non-animated parameters though. The proper time should always be used. There's very few reasons parameters should be non-animatible anyhow.

Here's a contrived scenario (a simpler version of one that I've run into on The Wild). The non-animatible parameter has a channel reference to an animatible parameter. This animatible parameter in turn has a vtorigin() expression which causes cooking of some other object. Say we're at frame 10. Now if the non-animatible parameter is evaluated at time 0, the vtorigin() expression will cook the object at time 0. But we're at frame 10, so this then dirties all nodes that are dependent on that object. In the problem that I ran to, "all nodes dependent on the object" happened to be practically everything in the scene causing extreme slowdowns. Basically, ever since we started allowing channel references on non-animatible parameters (necessary for HDAs), they can always be arbitrarily made "animatible".