I’ve saved a scop as a .spdl file.
I load it into a new scop (like a preset), and the “AlwaysEvaluate”, “Debug”, and “Mute” are missing. The scop functions, but doesn’t evaluate every frame.
Any ideas on getting it to evaluate every frame, or ideas on how to save scops properly for reuse on other parameters?
Scops can be created and attached dynamically within a run-once script. That’s usually the best way to go about it 9 times out of 10.
Yeah, you’re right, I see that will be the fastest way to apply an scop; like a deformation operator is applied.
Thanks Jaco
Even so, is there a way to make a scop update, without using the “Always Evaluate” feature? I looked into using the ProjectItem.EvaluateAt(frame#) property, but that only works with a project item; not a parameter. Unless I’m missing something.
Scops, like everything else, benefit (and occasionally suffer) from lazy evaluation.
If anything pulls the scene graph around it, and requires an output coming from the scop, the scop will be pulled.
Always evaluate is meant to be used for debugging or for logger scops or similar things that might be applied to something that doesn’t get pulled (IE the output port is on an hidden object).
A trick to force to always evaluate (always evaluation isn’t always as reliable as you might want it to be) is to have a scop parameter to be read in the scop, even if you do nothing with it, and applying a keyframe to that. That will basically always dirty the scop and make it evaluate on several events, including changing frames etc.
Ok, I think I understand.
My first approach to always evaluate was this use the PlayControl.Current as an input to the scop. It made sense that an input, that’s value is changing, did update the scop, but only if I manually picked a frame on the timeline. Simply playing back the timeline did not update the scop. So I ended up using the “always evaluate” option.
Now, you said to keyframe something in the scop inputs (even if it’s not used in the scop), and this forces it to update? I like clean, but I’ll try it, even if it is dirty.
Which brings up another question, is In_UpdateContext.CurrentFrame a dirty method for updating the scop? This is what I’m using in combination with the “Always Evaluate” option.
Ah, yes! I see now. The input object, a null in my case, is key-framed on the posx. This is an input to the scop, yet not used in the script of the scop. This forces the scop to update.
That will work as long as the null and object the scop is on are visible. Even simplier (and more compact) than that though you can just have a scop parameter (you can add parameters to one directly) with a keyframe on.
I’m looking into this right now, but thought I’d ask you, as well. Would I be able to achieve a more dynamic use of my scop by using the “SimulationEnvironm[b]ent”?
[/b]I’m reading up on this, but any help is appreciated.
Edit: I ask because I noticed the spring op has a simulation time control, and I was thinking something I need. Maybe not, I don’t know yet.
The simulation environment is convenient if your SCOP is stateful (springs tend to be), meaning you need to either read or accumulate data temporally, or at least propagate the previous frame state to the op’s current eval.
In general eval problems shouldn’t exist, and while not rare, they are at least uncommon.
What is yours trying to do exactly? The tricks I mentioned are workarounds, but they shouldn’t be the norm, giving up lazy eval is a pretty big performance tradeoff if your op is in a critical junction of the graph.
I’ve made a scop that is a sine wave deformer for a radius parameter for a sphere. I can now have it applied using ApplyOp(“myScop”, “mySphere”), and a line to key frame a scop variable called “Live”, just to have it always evaluate as we previously discussed.
Now, I’m considering using a caching method to “hold” the animation. Again, i don’t know if this is best.
Ultimately, I’d like to re-write this to be applicable to any parameter. My own custom sine wave operator for animating any parameter or object.
A wave op is normally just looking up a function in one or more dimensions, that makes it stateless and only needed when visible.
That means you shouldn’t need any simulation like qualities to it, nor forcing evaluation.
If you have input parameters to control the shape of the wave(s) then it’s all you need. Just keyframe one of those if evaluation gets stubborn (in such a case it really shouldn’t be though).
“live” if it’s a scop it will always be. What you want is probably time changing.
If you want the operator to be animated over time then just expose the wave’s time input, and when you need it to change over time put an expression on it with current frame for input.
From a design stand-point exposing the time input is by far the most elegant way to deal with it, because that way you not only can link it to scene time with a 2 letters expression, but you can also eventually decide to drive otherwise.
As for it becoming your own wave function, it should be perfectly possible.
Dynamic creation of scops figuring out whether it’s connecting to a point cloud or to a parameter can even apply the scop with different functionalities inside, but in general what you want to do can be Ndimensional, it’s just a matter of changing the number of times (and where) you feed and look up the function based on whether you output to a parameter or to 3Dspace.
If you’re using python, and feel adventurous, you can even do that in one piece of versatile code through Python’s introspection, by having the update call fetch arguments by introspection you can determine how many you have and how you want to work consequently.
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.