I was looking at some forum examples and playing around with doing them differently.

I don't use keyframes in my work, so when I tried modifiying an example that had keyframes I was puzzled as to why it was not working as expected in a foreach loop with feedback.

When I do an equivalent with an expression it does work as expected.

The for each loop is doing a cumalative boolean on geometry that gets fedback, being translated each time.(for each loop).

The values of the keyframed driven translation do apply to the intersecting geometry, but the feedback loop does not feedback the boolean results - Only on a per loop basis.

The expression driven one does both, again, giving the expected result.

In the hip file there is a switch node that can select and see the comparable results.

they are not the same

- with your keyframed method you are just animating the translate, so each frame the forloop does all the iterations with the same value of the current frame
- with expression you are varying the translation for each iteration

for that to happen with keyframed transform you'd have to use Timeshift SOP under the keyframed Transform and drive it by iteration

However your example overall may be more efficient with Solver SOP instead of foreach as currently it would have to recompute foreach from frame 1 every frame

tamte
with your keyframed method you are just animating the translate, so each frame the forloop does all the iterations with the same value of the current frame

Yes and that's 'interesting'.

Because at face value - in both cases, one gets a unique and expected value in the transform parameter;
Meaning both the expression and 'animated' values change/progressively about the same for each loop.

One just has to swtich to Single Pass mode to inspect and see that the values change uniquely for each loop.

It's like the for each loop won't 'disconnect' the source of the parameter values(in this case the animation driven ones) and just go with the actual parameter values on a per loop basis - even though the information to do that is all there, I.E. established static bezier curve, Frame Number to get value at specific point of bezier, Number of Loops.

tamte
be more efficient with Solver SOP instead

Indeed, the actual original example was with a SOP Solver, I was interested in looking at trying things differently for curiosities sake.

Foreach loop doesn't have concept of time
the fact that your number of iterations depends on $F is irrelevant, so if you think about what is happening is:

$F == 1
Foreach loop will run 1 iteration: 0
- Keyframed - it will use transform value at current frame
- your expression - will use iteration number * .125 so 0

$F == 2
Foreach loop will run 2 iterations: 0 and 1
- Keyframed - it will use transform value at current frame for both iterations as that's what the animation curve evaluates to, as it has no connection to current for loop iteration since you are not sampling the curve based on it or anything like that
- your expression - will use iteration number * .125 so 0 for 1st and 0.125 for 2nd

$F == 3
Foreach loop will run 3 iterations: 0,1 and 2
- Keyframed - it will use transform value at current frame for all 3 iterations, same reason as before
- your expression - will use iteration number * .125 so 0 for 1st and 0.125 for 2nd and 0.25 for 3rd

so you should start seeing what is happening, and hopefully it makes sense
in expression you are explicitly using iteration number while in keyframed you are not, so it just evaluates at current frame
(btw the expression also evaluates at current frame had it been time dependent on $F or something)
foreach loop iterations on their own don't change frame unless you control timeshift with iteration number or use chf() hscript expression to sample animation curve at a specific frame etc...

tamte
Foreach loop doesn't have concept of time

Yes this is true. And that is the crux of the matter that got my attention.

It doesn't, but it could - Since all the information is available to do so.

But I'm certainly not going to put in an RFE for such as I can't think of any need,
and like you said - a SOP solver is already available to take care of previous frame data.

BabaJ
It doesn't, but it could - Since all the information is available to do so.

it could but why would it do that?, why would it assume such convoluted use case as starting at frame 1 and increase number of iterations per frame and override internal time based on iteration ? Then you'd want a way to override that behavior and being able to sample some curves at global frame

it's much more common to iterate on a single frame, but vary incoming frame using iteration based Timeshift than having both frame dependent, but both are certainly possible using metadata

tamte
why would it assume such convoluted use case as starting at frame 1 and increase number of iterations per frame and override internal time based on iteration ?

It's only convoluted because you're still thinking in terms of the current context of how it works.

And there would be no increase number of iterations per frame.

The block of begin/end nodes can be a self contained unit of code that is run.

tamte
Then you'd want a way to override that behavior and being able to sample some curves at global frame

Yes of course, that's what I was saying - It could 'override'.

The end or beginning block could look at what is driving the count - and if a $F or similar trigger is present run the block of code/nodes within the 'loop' as time dependant for those places in which Keyframes are detected. So instead of sampling per frame, sampling occurs per loop count.

Another way, but more flexible is to have a multi-parm list in which the user decides which if any node/parameter that has a Keyframe to be sampled per loop specifically, while others(Keyframed parameters) could retain their default behavior linked to frames progressing.

It could also have a switch for turning it to per Frame mode(instead of detecting $F as before).
In such a mode along with Fetch Feedback, then the loop block does all the work per iteration/frame and retains memory of what was done for the next frame/ Instead of iterations increasing per frames progressing.

it could but why would it do that?

For greater flexibility and a block loop of code that behaves more like an actual loop - Thereby freeing up the end user to focus more on the logic of what they are doing instead of keeping in mind how it actually works. Being more akin to how loops in code are written and can be utilized when working with data.