Can loops be frame-dependent?

[Daniel_Daniel]

Can loops iterate over time? For example, iteration 1 - Frame 1; iteration 2 - Frame 2; ...

[Butachan]

Yes, just animating the number of iterations it will do.

You can just use $F in iterationson the block end if you are working on SOP and it will do the trick or just key frame it. Basically the same thing if you are doing it in vex.

Frame 1 = 1 iteration..... frame 10 = 10 iterations.

[anim]

use Solver SOP for such cases

otherwise, doing it by animating iteration count, you will be paying the cost of computing all iterations every frame up until the current iteration count (so frame 100 wil compute full 100 iterations from scratch instead of one from 99 to 100 as Solver SOP would)

[Butachan]

2 hours ago, anim said:

use Solver SOP for such cases

otherwise, doing it by animating iteration count, you will be paying the cost of computing all iterations every frame up until the current iteration count (so frame 100 wil compute full 100 iterations from scratch instead of one from 99 to 100 as Solver SOP would)

Yep to this. I was going to mention it, but I didn't want to overcomplicate the answer. But yes solver sop is the way to go for things like this.

[Daniel_Daniel]

solver wouldn't work for me, because you can't put it in compile blocks. I am looping through two opencl nodes, which for loop nodes can handle efficiently, because they are compilable

[Butachan]

But I guess then the efficiency will depend on how many iterations are we talking about. Things can go out of control easily in Houdini. Can you share an example file of what you are working on? Maybe we get a better picture. 

[Daniel_Daniel]

I am using the script from Houdini 16.5 Masterclass on OpenCL. In 58:09 Jeff shows how it works.

 

 

Edited February 3, 2019 by Daniel_Daniel

[anim]

15 hours ago, Daniel_Daniel said:

solver wouldn't work for me, because you can't put it in compile blocks. I am looping through two opencl nodes, which for loop nodes can handle efficiently, because they are compilable

you can compile the inside of the Solver SOP, and even do subsequent iterations within Solver SOP using internal For Loop to do subframe steps this way if you want to

however to carry over the results from of previous frame you'd want to use DOPs, so Solver SOP is the most straightforward way, if you want to get more optimized version use SOP Solver DOP and invoke compiled block directly, which saves you some geometry copying between SOPs and DOPs

also if your nodes are openCL you can directly use OpenCL DOP 

have a look at Vellum Solver DOP and see how various OpenCL and compiled SOP Solver DOPs are used

 

[Daniel_Daniel]

12 hours ago, anim said:

you can compile the inside of the Solver SOP, and even do subsequent iterations within Solver SOP using internal For Loop to do subframe steps this way if you want to

however to carry over the results from of previous frame you'd want to use DOPs, so Solver SOP is the most straightforward way, if you want to get more optimized version use SOP Solver DOP and invoke compiled block directly, which saves you some geometry copying between SOPs and DOPs

also if your nodes are openCL you can directly use OpenCL DOP 

have a look at Vellum Solver DOP and see how various OpenCL and compiled SOP Solver DOPs are used

 

Thanks a lot for those suggestions, that sounds very promising - I will do a test for Solver DOP then and see if I'll manage to get OpenCL code to work there.