The solution to this problem is to have the splice operator output onto the
PolygonMesh port of a dummy object, one that doesn't have anything to do
with the cloud we're pulling the data from. To then force evaluation in a
session without a viewport we just need to access the geometry of that
dummy object through a script. For Example:

 
Application.LogMessage(Application.ActiveSceneRoot.FindChild("Dummy").ActivePrimitive.Geometry);

Accessing the geometry forces the evaluation of the spliceOP because the
geometry of the dummy is its output. Evaluation of the spliceOP causes the
icetree on the pointcloud to be evaluated and because the operator lives on
a different object the full icetree can be evaluated before the spliceOP
pulls data from it, which avoids the error of pulling the ice attributes
when they haven't been set yet aka "Invalid offset specified while
extracting data from this attribute".

I hope this helps somebody should they stumble upon the same issue.

-Leonard

On Wed, May 6, 2015 at 12:23 AM, Mathieu Leclaire <[email protected]>
wrote:

>  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]> 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
>>
>>
>>
>
>

Reply via email to