Blink

One of the long standing feature request for Nuke is a itterator/feedback loop node, that would allow you to itterate over a node setup x number of times or as a feedback loop allow you to turn the output from the last frame into the top of the next frame.

General Iteration

Currently if you want to do any kind of itteration, you need to make a copy of your node setup for each itteratetion step. This means that you need to plan your setup ahead and that any playfull and creative modifications are out of question as the nodes need to be tightly setup with crosslinking expressions or predefined values.

(Xavier Bourque’s PxF_filler,Julian Lojek’s Expoglow and Xavier Martín’s X_Tesla)

Some people have made some helpfull scripts for making this process easier, such as Max van Leeuwen’s SetLoop node and it does help alot if you just need to make something quickly.

Temporal Iteration

But this is only accounting for general itteration. If you want to do temporal itteration or feedback loops, you could do node copies as above, but that would lead to a xⁿ problem where the first frame would be fast to compute since you only run your node setup once, but at frame 100, you would need to run the node setup 100 times and thus the render times would get slower and slower for each frame.

The remedy is to do a feedback loop where you render out the result of your node setup and read it back in to the top of the node tree at the next frame. A perfect example of this is Theodor Groeneboom’s 2D fluid solver Sprut. The big issue with this approach is the IO speed. Writing out a full exr and reading it back in takes quite a bit of time, and you loose a lot of the creativity and playfullness of having instant feedback.

The Blinkscript GPU memory allocation “exploit”.

I had some issues with Blinkscript when it was added back in Nuke 8, as under osx and linux the output buffer would not be initialized to 0. So if you used the random access pattern, and you had some pixels that you were not writing to, they would just be filled with whatever that buffer contained at the time of the allocation. Generally random garbage, but some times a “echo” of the previous frame. I reported it to Foundry and it got fixed shortly after.

While it was fixed for the random access pattern, point access still have the bug. And when Xavier Martín stumbled upon it, he made a interesting observation; That “echo” of the previous frame could be tamed to do a real feedback loop.

Generally speaking, if you imagine the read and write example from Sprut, but rather than writing the output to disk, you write it to GPU memory, as such the only overhead you get is the blinkscript initialization.

Here are two examples of the buffer exploit in action:

A test that Xavier Martín Ramírez did using a Houdini smoke sim: