Foundry invited me to SIGGRAPH LA 2019, to speak about BlinkScript, and do a booth presentation. I had a wonderful time and got a chance to speak with many from the Nuke community, the Nuke devs and the rest of Foundry staff. Here is the Blink presentation.
I would have assumed that the best way to do this would be to do the averaging and reformating in the same step to avoid having to make calculations that we throw out anyway. But after trying with blinkscript, expression nodes, transforms and matrecies i found that using the matrix node and throwing away the data was giving the best performance.
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.
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.
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 xn 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.
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:
One of the (many) things that can slow down Nuke scripts is a extensive use of Roto brushes.
Nuke does not do any smart cleanup of brushes after you lay them out, and that sadly leads to a ton a redundant roto points, that does nothing but take up space and make your script slower to process and autosave.
I also see a lot of people who use the roto brush-strokes extensively for beauty work, one good example being Nathaniel Westveer’s beauty work series on FXPHD. Where he first paint a stoke, then delete 95% of the points to get something that is easy to hand animate.
So i have created a little python script that uses Ramer–Douglas–Peucker’s algorithm to reduce the point count quite significantly. And you can get it right here: https://github.com/Malu05/NukePublic
One thing that you should note is that the roto.remove function is sadly quite slow, and when you expand it to hundreds of points it can get somewhat bad. You can optimize this greatly by writing your own function that does not remove one point at a time, but all of the redundant points at once (just re-write the whole shape).
After having a talk with Alex Fry from Animalogic, regarding hardware support in TheFoundry’s products, i took contact with the guys over at TangentWave to see if we could get support for their panels.
They provided me with their developer tools, and so i created a open Python socket controller, that allow you to connect the panels to any software you want, that have a python shell.
Once that was done i started some basic tests in Nuke, and have now added full support for all the panels in NukeStudio and Hiero.
In this video you can see me running NukeStudio with a full set of Tangent Element panels.
Once ready the full code will be made available on Github.
You can see all the tangent panels at tangentwave.co.uk/products/