> ../.. What I mean is: It might be later decided in C if the input of
A and B is needed.
> There might be something happening in C that doesn't require input
from A and B
> for this frame and so they don't have to regenerate their caches.
> More laziness so to say ../..
I see. Indeed this is an interresting issue.
It really depends on what your operator is doing. I believe it is
possible to organize things to suit this particular problem.
For instance, the 'decision process' wich evaluates the need for A or B
to update or not might be 'exported' somewhere else, to another Operator X.
The only job of this operator would be to make this decision and set an
input boolean of the operator A ( or B ), for instance.
I'm not saying it is trivial or obvious, but I believe this can be done.
Again, it would helps to describe some specific situation to see how
this can be handled ( if it can ).
PS: I'm not saying dirty flags shouldn't be exposed, of course. What I'm
saying is that if you expose them, and you push their use, ultimatly you
might end up with Operators with lots of inputs, but with their
computation done independently of the natural lazy evaluation of the
input connected object ( an object evaluation is triggered but you don't
need it - what the point ? ). Ultimately you'll make your decision tree
inside the Operator in a totaly independent way of the XSI graph. This
would defeat the natural lazy evalulation of the XSI operator graph, I
believe. But again, I'm not against the dirty flags feature. Just trying
to say that by relying on those dirty flags too much, you might miss the
oportunity to better design your plugin.
--
guy rabiller | 3d technical director (at) LaMaison
Felix Gebhardt a écrit :
Guy Rabiller schrieb:
> ../.. One disadvantage of this is that both operators
> A and B *have* to cache their results *just in case*
> operator C needs it../..
No, the point here is that operator C *was* caching datas anyway,
that was the first statement of the topic.
( Wich is why you need the dirty flag to only update C cached datas
according to the changed input ).
What I mean is: It might be later decided in C if the input of A and B
is needed. There might be something happening in C that doesn't
require input from A and B for this frame and so they don't have to
regenerate their caches. More laziness so to say. Now telling A and B
their input is not needed from C seems difficult as the evaluation
order is not known.
> ../.. don't provide workarounds for
> this or we will never get dirty flags../..
You are assuming that I'm listenned. Don't count too much on this ;-)
More seriously, I don't considere this as a "workaround".
For me it's more a different approach in organizing the flow of datas
wich does not suffer for the lack of dirty flag.
( because it is not based on dirty flags )
Ja, I agree, it works well for 95% of the cases and workaround was a
bad word for it. Still: Dirty flags please! :)
F.
---
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
