Unit component

Since this need was brought up by the new loop component, it might actually be better to add a Variable slave component wherein one can pass a single numeric result to the next stage of the loop, similar to the Randomizer, but user set. Also in this case, one would have to be able to pick the variable fr om an RGB or grayscale image, so the same idea as above but lim ited to the loop.

Perhaps the simplest implementation of this idea would be to make the Lookup component have a "Flat fill" option to it where it would assume that the X and Y coordinates do not vary (pick the center point or 0,0 point and then look up that coordinate from the Source. The important thing is that the component would only have to look the point up once (per loop) and pass that value. (As opposed to sampling it for every pixel + every subpixel needed for antialiasing.)

I wouldn't mind a similar solution as a Loop slave component. The main thing is to be able to pass one value in the same fashion as the slave components.

Back to the attempted Non-overlapping circles filter, if I replace the Lookup with a Randomizer, I can render one thousand loops or more. But attempting to look up ONE sample from Accumulated, I get to about 7 iterations. The situation should be comparable: Pass one random value or pass one sampled value. Yet one runs linearly, the other exponentially unless something is changed.

Unfortunately the current implementation wrecks about 9 out of 10 loop-based ideas I have.

(I'm thinking about this. Implementation-wise, Loop is very tricky, especially when the mappedness of things is involved.)

It appears (to an outside observer like myself) that every iteration passes new Position, Iteration and Randomizer values. So you are saying that all iterations of these values are evaluated (in the internal "Prepare" function) before sampling begins, so that they are in fact constant throughout sampling?

So this probably means that even the "Flat fill" option in some components works this way -- it actually does a lookup for every sample although they come fr om a lim ited number of source coordinates?

The funky part is, it is very easy to script a "sample once, pass the same value thereafter" Script component, but it won't work with a loop, for it will pass the same initial value for every subsequent iteration of the loop. Which is why I tried to sample the Iteration slave component to detect when the Iteration changes. In theory it would work, in practise there must be something I don't understand or know, for it doesn't.

Most fundamentally, IF I can make something happen with a LUA script, you could make it happen internally, because the logic is basically the same, right?

Ok, thanks, that clarifies it. And no, I hadn't noticed that the Slave component inputs are green!

Quote
Regarding the rest of your post (actually, thread), I'm still trying to wrap my head around all this. It haven't clicked yet.

But I assume that you understand the basic problem I am trying to resolve, right?

Until you guys figure out the awesome generic auxiliary/multi channel fix (in line with grayscale and color mapped you would introduce multichannel mapped inputs), I think the idea of adding a handful additional accumulator paths is a great compromise

Additional accumulators: That could work, if it avoids the branching issue. I don't know if branching the accumulator internally (as opposed to the filter tree) makes a difference or not.