BlinkScript and OFX
Running Nuke Blink kernels on the GPU, and loading OpenFX plugins.
BlinkScript
The BlinkScript node runs Nuke Blink kernels. There is no C++ compiler involved: each kernel is translated to a GPU shader.
- Edit the kernel source in the node's panel and press Recompile (Ctrl+Enter). Each
param:becomes a knob, each input image becomes a node input, in the order they are declared. - Errors are listed with their line numbers; the node keeps its old knobs and outputs nothing until the kernel compiles.
- Kernels in .nk scripts import with their source and parameter values, and export the same way.
- Positions are in Nuke pixels (origin bottom left, y up). Edge modes
eEdgeClampedandeEdgeConstantbehave as in Nuke.
Not supported:
| Kernel feature | Why |
|---|---|
writing to another pixel (dst(x, y) = …, scatter / splatting), atomicAdd | each output pixel is computed on its own |
ImageRollingKernel, ImageReductionKernel | they need to run pixels in order |
eReadWrite images (ParticleBlinkScript, in-place writes) | same |
In a test set of 120 real-world kernels, 104 translated and ran.
OFX plugins
Oink loads OpenFX image plugins (the plugin standard of Nuke, Resolve, Natron and Flame). Each installed plugin becomes a node on the OFX button of the node toolbar and in the Tab menu. Plugins run in a separate helper process, so a crashing plugin cannot take the app down.
A GPU plugin shares the graphics card with other heavy jobs. If an AI or render job holds the card, the Viewer waits at most 5 seconds (OPENCOMP_OFX_LEASE_WAIT_S), then the node shows an error naming the job and passes its input through; the app never freezes. Background renders wait longer (up to 10 minutes). Frames sent to a plugin are cached in memory, up to 4 GB (OPENCOMP_OFX_FRAME_CACHE_MB).
Where plugins are found, and how they are saved in .nk files: OFX plugins.
Gizmos
Gizmos are covered in .nk import and export: put .gizmo files in ~/.nuke, ~/.opencomp/gizmos or a folder on NUKE_PATH and they appear in the Tab menu.