Yeah, we had the same problem but for us it was for rendering. We had
put our SpliceOp on a Null and since Arnold was never pulling the null
data, the operator was never evaluated and it didn't render. So we put
the Splice Op on a mesh, a very tiny sphere that was being passed to
Arnold so the SpliceOp was then evaluated. That worked for us, but I've
been wondering if there's a better way to force the evaluation of the
SpliceOp in Batch mode. Let us know if you find anything better, but you
could try something like that. Put the SpliceOp on an object and force a
render of that object (render a temporary black frame if you need to)
and that will pull the SpliceOp evaluation and do what you want it to
do. It's not the most elegant solution, but it's an idea worth trying I
think.
-Mathieu
On 05/05/2015 6:04 PM, Leonard Koch wrote:
Thanks Jason.
Yeah that is interesting information. I had already figured that part
out though (see my response to Renaud).
It is very neat though to see it all described in detail.
We're now having this weird issue of splice not being able to pull ice
attributes when forced to evaluate this way.
I will report back here once I have that sorted out.
On Tue, May 5, 2015 at 8:31 PM, Jason S <[email protected]
<mailto:[email protected]>> wrote:
On 05/05/15 9:15, Leonard Koch wrote:
We're running splice in Softimage to render out a pointcloud
using a renderer written in KL.
Sounds cool!
Would this help? (see related tip)
from here:
http://softimage.wiki.softimage.com/index.php?title=Custom_Operators_%28XSISDK%29#Forcing_an_operator_to_update
Forcing an operator to update
A common scripting problem is that a scene that works well in
the UI may not work properly when processed via a script,
especially when running in batch mode. This happens most
frequently when dealing with simulation situations such as
Syflex, Hair, Particles or export of animation or with Custom
Operators.
The reason is because XSI is highly optimized and does not
call the update method of an operator unless something "pulls"
the objects that the operator outputs too. In other words, XSI
does not generate data unless it is asked for. This /pull/
often occurs when the object is drawn on the screen because
XSI wants to determine the exact accurate visual
representation of the script. The result is that an operator
may have its inputs changed, which puts it into a /dirty/
state, but not automatically update itself.
Fortunately XSI is not dependent on its UI, so other
scenarios, including the SDK and rendering can also cause a
"pull of the scene graph".
For example if an operator modifies the geometry of an object,
then any SDK code that retrieves the geometry will provoke the
necessary Updates.
So a script that wishes to perform some sort of batch
simulation or animation export should be sure to access the
affected objects using the SDK at each frame change.
*Related Tip: *Some custom operators that run simulations need
to be dirty each time the frame position changes.
Use the CustomOperator.AlwaysEvaluate property to establish
this behavior.
(The older workaround was animate a parameter of the operator.
This parameter could be hidden and just served the purpose of
making the operator dirty at each frame)
On 05/05/15 9:15, Leonard Koch wrote:
We're running splice in Softimage to render out a pointcloud
using a renderer written in KL. So the renderer lives in an
operator on the pointcloud.
When we open this scene using xsibatch the splice operator
doesn't get evaluated.
Just like any other part of the scene wouldn't. Because it
doesn't have to, because it isn't displayed anywhere.
Is there a way to force softimage to evaluate its graph without a
viewport?
Would really appreciate some input on this.
Thanks!
-Leonard
