Re: Bad Operator Update

[Nick <nick.petit(at)gmail.com>]

You're right, if the string parameter value changes, the Op automatically registers the entire prop as being dirty and forces it to be evaluated... I don't know what I was thinking, sorry for the bandwidth...
 
Strings are really painful though, not being able to connect them directly, animate them or even set expressions on them... Houdini has some awesome syntax you can use which makes it very powerful and would be extemely handy, especially if you are passing strings to custom properties (in my case, 3delight shaders whose parameters are tweaked via custom properties)... 
we need animatable strings, smarter expressions that deal with basic string parsing and something that allows us to maintain/create custom object connectivity without having to jump through hoops like we do at the moment, but that's for an entirely different thread...

On 9/14/06, Guy Rabiller <guy(at)alamaison.fr> wrote:

They are ok, as being parameters, any change will be notified to the
operator.
String parameters can be 'connected' to an operator.
For exemple when you use a string parameter for file path name used by
an operator to load datas.
Any change to the parameter will trigger operator evalulation.

On a side note, unfortunately, string parameters are not animatable yet.
It has been a requested for long a time.
--
guy rabiller | 3d technical director (at) LaMaison


Nick a écrit :
> string parameters?
>
> On 9/14/06, *Guy Rabiller* <guy(at)alamaison.fr
> <mailto:guy(at)alamaison.fr >> wrote:
>
>
>     > ../.. So it's approprate for cases when you have
>     > some noise function based on time, for example.
>
>     or when writing to/reading from disk.
>
>     Basicaly, this means that something changes without the Operator
>     beeing
>     notified.
>
>     And what changed in those cases ?
>
>     Time. And Time only. And Time wasn't 'connected' as an input of the
>     Operator.
>
>     So rather than to toggle the 'always evaluate' flag, better 'connect'
>     the Time factor to your operator, meaning adding a parameter with an
>     _expression_ such as Fc.
>
>     Now the Time value is 'connected' and your Operator will be properly
>     updated, every frame.
>
>     May be I'm missing something, but this 'always evaluate' flag should
>     disappear. It gives wrong habits and it is against the lazy evaluation
>     mechanism. It should never has been exposed at first.
>
>     What kind of value, except for Time, could affect an Operator wich
>     would
>     need the 'always evaluate' flag to be turned on ?
>
>     What kind of value wich cannot be 'connected' to an Operator through
>     parameter _expression_ or other type of input ?
>
>     --
>     guy rabiller | 3d technical director (at) LaMaison
>
>
>
>     Luc-Eric Rousseau a écrit :
>     > right - in an operator architecture, you can't assume the input
>     is the same object as the input, even you made that connection
>     yourself.
>     >
>     > The system is always free to replace either input or output with
>     a cached buffer, for performance purpose, and if often does.
>     >
>     > The 'always evaluate' flag should rarely be used, and any use of
>     it should be looked at carefully.  It's meant to be used when your
>     operator changes its result for each frame, even if there are no
>     parameters animated, and the input is not changing.  So it's
>     approprate for cases when you have some noise function based on
>     time, for example.
>     >
>     >
>     >
>     >> -----Original Message-----
>     >> From: Helge Mathee
>     >>
>     >>
>     >> No I don't.
>     >>
>     >> When you create a scripted op on let's say the kinematics.local
>     of an
>     >> objects,
>     >> the scop contains two ports. One called something like Inlocal
>     and one
>     >> called Out.
>     >>
>     >> To make sure the evaluation is done correctly, you'll have to
>     use the
>     >> transform coming from the input port, not the one from the
>     >> output port,
>     >> as you are WRITING to the outputport, and READING from the
>     input one.
>     >>
>     >> example:
>     >>
>     >> var xf = Inlocal.value.transform;
>     >> var pos = XSIMath.CreateVector3();
>     >> pos.Set(10,0,0);
>     >> xf.SetTranslation(pos);
>     >> Out.value.transform = xf;
>     >>
>     >> cheers!
>     >>
>     >> -----Original Message-----
>     >> From: owner-xsi(at)Softimage.COM <mailto:owner-xsi(at)Softimage.COM>
>     >> [mailto: owner-xsi(at)Softimage.COM
>     <mailto:owner-xsi(at)Softimage.COM>] On Behalf
>     >> Of Daniele Niero
>     >>
>     >> Hi Andy,
>     >>
>     >> Are you suggesting me to create and use a different Transformation
>     >> object, manipulate it and then put it in the
>     >> output.kineamtics.global.transform ?
>     >> Did I understand?
>     >>
>     >> Hi Mathee,
>     >>
>     >> Are you saying the same thing Andy is saying? If not I don't
>     get it.
>     >> I cannot use as output the final channel, for example
>     >> obj.kinematics.global.posx, because this means I have to use 6
>     output
>     >> instead 1 as so have 6 update instead 1.
>     >> What I'm missing?
>     >>
>     >> Thanks a lot to both of you guys
>     >> Daniele
>     >>
>     >
>     > ---
>     > Unsubscribe? Mail Majordomo(at)Softimage.COM
>     <mailto:Majordomo(at)Softimage.COM> with the following text in body:
>     > unsubscribe xsi
>     >
>     >
>
>
>
>     ---
>     Unsubscribe? Mail Majordomo(at)Softimage.COM
>     <mailto:Majordomo(at)Softimage.COM> with the following text in body:
>     unsubscribe xsi
>
>



---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi