Hello,

I was hoping if someone knew how to keep a created value as a result of a specific frame number persistant for successive frames.

Just to illustrate the intent I thought this might work with the point wrangle set at Detail ( only once ):


I know I can do this with the Python Source editor that keeps a ‘defined’ variable I write acting like a ‘Global’.

But I thought I could do the same with a defined ‘attribute’ ie. I thought the @ref would persist to the next frame.

But it seems Detail(once only ) means once only per frame evaluated vs running over all ‘x’ per frame evaluated.

If someone happens to know if there is a ‘simple’ way to do this staying in a vex context I would appreciate knowing;

Otherwise I guess I will just use the Python Source Editor and create a spare parameter with the above similar code to set the Global to persist and just pull that in the vex with a channel reference.

Thanks

Geometry nodes, (SOPs), don't explicitly know about their results from any other frames. However, there are a few ways that you can get a value that's the same across frames.

A) Don't make the value depend on time.

I know this sounds self-referential, but it's the most common way to have values that persist across time. If a whole node and all of its dependencies don't depend on time, it will only cook once when playing back. If the node is time-dependent for other reasons, but the specific parameter or attribute value being referenced doesn't change value over time, the node will still re-cook, but at least it'll get the same value all the time. In Houdini 16.0, if you press and hold down the middle mouse button on a node, the popup will say “Time Dependent Yes” in green if the node is. There's also a little green clock icon next to time-dependent nodes.

In your example, if the position of point 0 in “/obj/ShiftingPoints/blast1” doesn't change over time, it should be fine just to do:


Sometimes, you'll have things that can be split into time-independent and time-dependent parts, which can speed up using the time-independent values, since they only have to be computed once. An example is using a Scatter SOP on time-independent rest geometry once, and then using Attribute Interpolate with the points from Scatter and the time-dependent deformed geometry to move to points to their deformed positions. This avoids redoing the Scatter on every frame and can avoid quite a few problems.

B) Use a Time Shift node.

If something depends on time, but in some case, you just want to use the value from a particular time, (and it can't be easily separated out into time-independent and time-dependent parts), you can use a Time Shift node to make upstream nodes cook at a particular time or frame. Note that if those upstream nodes were previously cooked at a different time or frame and they're time-dependent, they'll cook again, so this approach can cause extra cooking if you're not careful.

In your example, you could have a Time Shift node set to evaluate at frame 1, with the same VEX code in Attribute Wrangle set to Detail going into the input of the Time Shift:


Since it's only being evaluated at frame 1, it'll only ever have the value from frame 1.

VEX has Context (or Containers):

Detail -> Primitive -> Vertex -> Point

You could create a Detail attribute in a Wrangle set to Run Over “Detail (only once)”.

Then in a Point Wrangle, reference the Detail attribute you created upstream.

Thanks ndickson and Daryl.

Yeah, the points in the wrangles are going through changes over time as a result of references to changing values in a Chop network.

And yes even though the wrangle is set to Detail ( only once ) it still gets evaluated every frame.

The referenced Data in Chops is changing per frame, so the points do too.

Yeah, the Time Shift Node looks like an idea worth a try, although I will be facing the caveat you mentioned.

But it sort of reflects the original “brute” force idea way of doing it that I had, which is not very ‘elegant’ at all.

Just make 2 copies of the sequence of nodes/code and have seperate chop network/functions behave differently at the desired frame to give a non-changing value at that frame.

Haven't used the time node before…so I guess I'll have to experiement with that one then.

Although, I know in general it can be ‘bad’ programming practice to use globals and in the context of Houdini could bring up potential issues.

The ability to create a global at any given frame has alot of potential application for making use of vex, when those vex functions are heavily user defined.

But..that's for another discussion.

Thanks again for your input guys.

Well….tried the timeshift node.

So far ….works like a charm.

It only requires one line of code to access the value with the detailattrib function from any other vex contex.

In that way, it is behaving like a global and the implementation is simple too.

Thanks again ndickson.

works for me too, it helps me a lot !
thanks !!