Scripting and multithreading

I ran into the issue of multithreading in trying to store variables during the get_sample() function.

Apparently, if you initiate a variable in the prepare() function and try to use that in get_sample(), it will work independently in every thread.

At least so it has been with what I've tried to do.

For example, this script uses a counter to try and control when to start and stop a process. However, the same counter is used independently in every single thread.

Is there a way around this?

TD

Here's what I'm trying to do.

I want to make a "Ramp" filter which is a sort of wind blur type filter. The color values decrease in one direction until a higher value is found.

By calculating the ramp for every single pixel produces the correct output.

Render time is just 0.65 seconds, but the result is a wreck.

Now, if I could just turn off multithreading (is that possible?), it would be correct.

I can think of a rather complex handling: treat each thread image rectangle as a separate image and write code that takes this into account.

Seems messy.

Anybody know of a simpler handling?

Well, I tried my complex solution and it worked, at least to a degree.

Looks just like it should and renders in 0,63 secs.

The only problem is, it works beautifully with antialiasing turned OFF. Turning antialiasing ON messes it up as my script doesn't know we're now taking more samples. Once I sort that out, we'll have a Ramp Scrippet.

Ah! That looks good, I thought it would screw up your ramp vars somehow.. I'm curious to how you're rendering this

Bugger! Yes thats what I meant.. not img -> distorter -> script, but img -> script -> distorter.

As you see, I use the variable "counter", which is used once for every thread. After that the full calculation backwards from (x, y) is done when x=x0, that is, at the left edge of each render rectangle. In all other pixels, the stored value is "ramped" down and compared with the current value.

Thus the script does two different things depending on whether it is the leftmost row of pixels in each render rectangle or not.

A quick overview of how we implement multithreading in FF scripts:

1. Script components are executed in separate Lua interpreters (Lua's internal term is "Lua states"), so they can't communicate.

2. Before the rendering begins, we create a single Lua interpreter per script component and execute the prepare() function.

3. After the prepare() call has been successfully completed, we copy the Lua state (variables, tables etc.) into several new Lua interpreters, one per rendering thread, so when the rendering begins, each script component has as many Lua interpreters as there are rendering threads, and their states are identical.

4. The rendering is done per-block. We create Lua interpreters and initialize them with the state described in p.2 for every block. When a block is successfully rendered, we just kill its Lua interpreter without preserving its state.

Quote
Sphinx. wrote: A noise distortion is not really distorting its source.. it is distorting the coordinates passed to the source..

Exactly. Here's an example script from the Help article (don't forget to add the inputs):

Quote
function prepare() end; function get_sample(x, y) rd, gd, bd, ad = get_sample_map(x, y, DISTORTER) samplex = x + (rd + bd/2) * ad sampley = y + (gd + bd/2) * ad r, g, b, a = get_sample_map(samplex, sampley, SOURCE) return r, g, b, a end;

Note that the second get_sample_map() call uses different sample coordinates than the original sample coordinates supplied to script's own get_sample() via its x and y arguments. Filter Forge components, including scripts, are free to sample their map inputs any number of times at any sample coordinates, and they can use the RGBA values returned by these calls in any manner, including the calculation of sample coordinates for subsequent sampling calls, as in the example script above.

(This was an excerpt from the Help file I'm currently working on.)

Quote
ThreeDee wrote: Okay, so what I get from all this is that the x and y coordinates of the get_sample(x,y) function cannot be expected to be processed in a linear fashion, NOT EVEN WITHIN A SINGLE RENDERING BLOCK, so scripts have to take that into account.

Not even within a single pixel.

Yes, that's correct.

I believe I now understand why a distort component messes this up: The sampling process goes in reverse, later components querying earlier components. Thus the upstream distort component queries the (x,y) samples in the sequence they are needed to render the Distort component, from the previous Script component.
So, I need to take into account both multithreading and sample-based rendering process if I want to store values in variables or tables.