Jump to content
Daniel_Daniel

Can loops be frame-dependent?

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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

 

 

Edited by Daniel_Daniel

Share this post


Link to post
Share on other sites
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

 

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×