does anyone know a way to break a for loop sop which is enclosed inside of compile sops?
seems compile sops ignore the expression written inside ‘stop condition’ parameter in for loop's ‘block end’, and may be expressions in overall.

(Sorry for momentarily letting a spam bot in.)

Could you post a HIP file showing this issue? It might be something simple to work around or fix, but it's hard to know without an example.

hi @ndickson

unfortunately i am not successful to upload the HIP file. after attaching the file and hitting the submit button, attached is not uploaded, just text.
here i describe a very much simple setup i had.

1. put down a box
2. create a for loop (iteration method: By Count)
3. inside the loop put down a delete sop (Entity: Points, Pattern: 0)
4. in for loop block end (Stop Condition: npoints( ‘../delete1’) < 5)

5. construct another version of above steps, but this time inside a compile block.

actually in every loop iteration we want to delete one more point of the incoming box, until we reach to 5 points.
increase the ‘Iterations’ parameter in each ‘block end’s to see the difference.

Unfortunately, the stop condition on For loops is not supported yet inside compile blocks. This should be documented in the section on Compiled SOPs in the most recent builds, but I think I overlooked this note in the gold release.

If it were supported, you would have to use npoints(-1) since compiled nodes need to use spare inputs. The problem is it is unclear if spare inputs to a for end block should be evaluated before or during the for loop. Currently they are evaluated before; allowing you to control the number of iterations through the parameter. But this makes the stop condition not work.

In this case you could just set your number of iterations to
npoints(-1)-5
but I understand it is not always easy to rework a problem. (which is why we have a stop condition, after all!)

thanks @jlait

I want to reach to an specified number of points for varied geometries with varied number of points as inputs to the loop and inside the loop also just a chunk of the input geometry gets isolated according to some criteria as the input of the delete SOP (unknown number of points). so we need to count number of points of delete SOP in every iteration to check we reached that specific number of points or not. obviously filling spare input by the nodes placed inside the loop causes errors and as you know makes your trick unused. so no real resembling of stop condition.

And regarding the problem of being unclear, if spare inputs to a for end block should be evaluated before or during the for loop, could not be a solution to give us a control to decide manually which one should be performed depending on the pros and cons of each, in different scenarios? for example in our simple test scene, we are aware that delete SOP surely placed inside the loop chain.

Anyway, will this be a persistent architectural limitation of compile SOPs or will be removed in future builds or versions of Houdini? it prevents (limits) us to benefit from one of the main advantages of using compile blocks. multithreaded while (for) loops for processing networks which are dealing with heavy geometry sets, without a pre-known end number of iterations.

Anyway, will this be a persistent architectural limitation of compile SOPs or will be removed in future builds or versions of Houdini?

The intent is to either remove this limitation, or provide some other mechanism to break loops in a compile-friendly fashion.

Good news. because what i am working on now, highly depends to this functionality. so i can continue my work by some considerations, till updates.

Just as a side note to think about:
stop condition is usually used for For loop that feeds back the previous geo and modifies it until certain condition is met
and in that mode I'm not sure how much compiling the For loop can help
as compiled For loops can run multithreaded only when each iteration is independent, so not in feedback mode
so in the case of feedback I'd rather compile inside of the for loop and therefore stop condition should still work, than trying to compile the For loop itself
so while being able to use stop conditions inside of For loops would be great it may not hurt you as much as you think unless you have it as part of greater network that you want to have compiled together

One place where multithreading does show up is if you want to apply that sort of conditional loop to many items at once. So a For Each loop, and within the For Each, you have a For Loop. Here you want the outer foreach compiled to multithread.

In addition to what has been said Tomas, your last paragraph actually describes what i was thinking about too. putting a huge network inside just a single compile block, for maximum versatility instead of patching a bunch of compile blocks as a hack way to overcome this For loops limitation which is suffering from some major performance issues. having a huge network means having lots of loops. developers write software and hit compile once to get the executable binary.