Re: Bad Operator Update

[Guy Rabiller <guy(at)alamaison.fr>]

> ../.. 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] 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 with the following text in body:
> unsubscribe xsi
>
>   



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