Re: A Question About C++ "SICO" Development

Date : Fri, 25 Aug 2006 13:56:38 +0200
To : XSI(at)Softimage.COM
From : Felix Gebhardt <gebhardt(at)betacarotin.de>
Subject : Re: A Question About C++ "SICO" Development


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


Search the XSI List archives here or use the advanced search form to search across mailing lists. Searching help is available.
This site supposedly brought to you by Benjamin Grosser and the Imaging Technology Group.