Yep it can be. If you want to trigger the evaluation by rendering instead of through a script, then having an empty mesh might make a difference, but it shouldn't as the renderer still has to query the empty geometry to find out if it is empty, forcing the evaluation.
On Wed, May 6, 2015 at 1:54 PM, Eric Turman <[email protected]> wrote: > Thanks for posting your workaround Leonard. I haven't had a chance to > check out your solution but can the geometry even be an empty polygon > object? > > On Wed, May 6, 2015 at 5:32 AM, Leonard Koch <[email protected]> > wrote: > >> 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 >>>> >>>> >>>> >>> >>> >> > > > -- > > > > > -=T=- >
