Loop with Script > Blend weirdness

The filter in question.

Non-overlapping Circles.ffxml

Replacing the Script with Lookup works correctly (but awfully slowly).

Non-overlapping Circles 2.ffxml

Indeed yes, to make the circles non-overlapping. So if they are too close, the radius is decreased.

Hmm.. I experienced some strange things similar to this myself, but its not like we're getting a crash or anything..

What happens if you use the faster alternative Min from the RGB Math category?

It could be the same problem as I have in the Julia filter (take a look at the one I posted in the beta gallery thread) - I can't use the Iteration slave node as it seems to stick at the max iteration value during the real rendering. I'll see if I can make a simple bug example.

You can try my temporary solution from the Julia filter. I basically just use one of the channels to keep track of the iteration (initialize with the value 0 and then add 1 in each iteration)

Btw, not sure it is related to what you're doing, but here is an ultra simple loop based cells

Cells (Loop).ffxml

ThreeDee, I'm trying to understand the bug you posted in the original post. I took a screenshot of Tone Curve and Accumulated and tried to blend them via Darken in Photoshop. This is what I got -- is this what you expected from the Blend in question?

(I also tried to replicate Darken with Min, and they look identical, just as they should.)

Quote
I took a screenshot of Tone Curve and Accumulated and tried to blend them via Darken in Photoshop. This is what I got -- is this what you expected from the Blend in question?

Hi Vlad. Yes, exactly. That is what it is supposed to look like. Only ONE branch goes through the Tone Curve but the result is as if BOTH branches went through it.

You get the right result if you replace the Script with Lookup with the same X and Y inputs (The "Step" input is not needed for Lookup, it just checks whether a new loop iteration has been entered).

Yes, it appears similar -- although there is no Grouping involved here, rather a Script.

This is the simplest I can make it. If you go to Iteration 3 of the Accumulated, you can see that in the Blend the Radius of the Free Polygon (or Ellipse) is funky, it is unaffected by the Script result, although the Free Polygon itself is affected by it ...

Again, if you connect the Lookup instead of the Script, all is well.

Script Loop Bug.ffxml

Here's my attempt at reproducing a stripped-down version of the "bug". When you adjust the Gamma slider, all ellipses change, as if they all have been processed by the gamma -- which is precisely what's going on! Every single ellipse that went through the Loop was indeed processed by the same Gamma curve, and that's why they all change when you adjust Gamma.

Is this example comparable to your case?

All_As_One.ffxml

Hmm.. I think there is a problem with the Script configuration: it should have HDR enabled on the inputs (at least on the step input). The lack of HDR support will result in the same lookup value, the same tone curve settings and hence the similar tone adjustment.

Btw I encountered a bug related to this HDR change..

The same Gamma is added to the Accumulated output before (or during) Blending. The Accumulated clearly doesn't have the Gamma applied, only the branch that goes through the Script.

Guys.. disconnect the script, enable HDR on the step input and reconnect

Well, I'll be damned. That was the problem! Never noticed that little checkbox on the inputs, only the "can output HDR" option....

My only remaining question then is: Why on Earth is it still so slow? Can I make some sort of "initialize trick" for the Script for every beginning loop to speed this up? Looking up one additional sample per loop should not slow things down this much.

You're not alone .. that default setting has fooled me so many times now. I really wish the default setting was the other way around, i.e. HDR enabled by default - that would allow both HDR and non HDR pipelines.

About the speed - from what I see you're branching x2 in each iteration. The cache you implement is not really working because (I think) each iteration has its own scope, so you can't cache v across iterations.. is that right Vlad?

Btw. there was a mistake in my old Julia sample cache, I fixed that and added an even smarter approach to the cache setup. There might be something for inspiration

Native Julia Set (1).ffxml

Quote
It also crashes if I try to change the Script identifier for Script Component "Y" input, on pressing OK in Input editor after changing name.

We've fixed that, to be released in the next hotfix.

Quote
Would it be possible to initialize, that is to run the Prepare function newly for each loop? As far as I can tell, it is only run once, for the first loop iteration.

The Prepare() function runs once, before the rendering (i.e. the sampling process).

Quote
Otherwise it would be very simple to construct a Script that picked the value of a single point from an image (once for each iteration).

Shouldn't this code be placed into script's GetSample() then?

Ah, I recall the annoying change to the scripting engine that was introduced to "fix" multi-threading issues: Each rendering tile (the small incremental blocks we see during rendering) has its own scripting scope.

This means that even with a single lookup based on a fixed coordinate, the cache script will be initialized blockCount^2 times. That is 64 for the default resolution. This means that we essentially can think of this as a forced non cached 8x8 pixel rendering. Taking the branching at 10 iterations into consideration that ends up being (8 * (2^10))^2 or 8192x8192 samples just to cover the render tile "resolution", i.e. the initialization of render tile scripting scopes.

This is just speculation of course - it would be nice if Vlad or Egret could shed some light on this.