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