> ../.. In the final operator there might be two different
> states. One that needs this data and one that doesn't../..
I understand the issue, but the needed key information to allow proper
solution is to answer this question:
What for and why the operator has two states, one that needs this data
and one that doesn't ?
It's only by digging deeper that this kind of specific problem can be
solved.
> ../.. I'm not sure how to handle the pull
> part with separate operators../..
Either by extracting the decision process from the Operator C.
or
by evaluation 'on demand'. Wich means that operator C would be evaluated
*before* A and B.
This would require a new XSI Operator feature, another callback aside
the '_Update' one.
An '_Evaluate' callback for instance, an evaluation 'pass' wich would
set evaluation flags on inputs, before the operator is updated.
This way you would not have to disconnect an input if you don't want an
evaluation triggered on that input for some reason.
This would be a cleaner approach than dirty flags, I believe.
--
guy rabiller | 3d technical director (at) LaMaison
Felix Gebhardt a écrit :
Guy Rabiller schrieb:
Again, it would helps to describe some specific situation to see how
this can be handled ( if it can ).
Say you have a polygon mesh on the input for that you build an
acceleration structure. Now this might be static or shape animated. In
the final operator there might be two different states. One that needs
this data and one that doesn't. Now the optimal solution would be to
only recompute this acceleration structure if a) it has dirty
inputs/the mesh changed and b) the data is actually needed/pulled. I'm
not sure how to handle the pull part with separate operators as only
connecting a blob as input to the "master" ( formerly called C )
operator for example makes the other operator ( A ) considered as
pulled (understandable as XSI doesn't know what you are up to). It
would be easy to handle "pulled" correctly inside the "master"
operator though.
On the other hand treating it your way this structure would stay with
the object it belongs to and would be exposed to other operators which
might be handy.
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.
I totally understand what you are saying. Replicating lazy evaluation
inside of an operator makes it's modules less reusable and less
transparent. It's just sometimes it would come handy.
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
