.nk import and export
Opening, importing, exporting and copy-pasting Nuke scripts; Unsupported nodes, Groups and gizmos.
Oink reads and writes Nuke's .nk script format. Its own comps are .oink files; .nk is for exchanging work with Nuke.
Ways in and out
| Action | What happens |
|---|---|
| File › Open Nuke Script… | replaces the comp with the script; the script's frame range, fps and format are applied |
| File › Import Nuke Script… | adds the script's nodes to the current comp (names made unique) |
./launch_opencomp.sh shot.nk | opens the script at launch |
| File › Export Nuke Script… | writes the whole comp, or only the selected nodes |
| Ctrl+C / Ctrl+V | the clipboard holds real Nuke node text: nodes copied in Nuke paste here, and nodes copied here paste into Nuke |
After an import, a summary lists the Nuke classes that had no equivalent.
How nodes are translated
- Each Nuke class maps to one node; the full list is the Nuke node map. Knobs with the same name carry over; renamed knobs are translated both ways (each node page lists them). A .nk knob with no match on the node imports as a knob of the same name, or is kept unchanged so it is written back on export.
- Unsupported nodes. A class with no equivalent becomes an Unsupported node: drawn red, all its knobs kept, input 0 passed straight through. On export it is written back exactly as it was read, so a round trip through Oink does not lose it.
- A node's
labelthat only repeats its own name (an old automatic label) is dropped on paste and import, so a renamed node does not show two names. - Knobs we do not use are kept and written back unchanged.
- Groups become real Group nodes; Ctrl+Enter opens one, Ctrl+Backspace goes back up. Nested groups work.
- Gizmos. A class that matches a
.gizmofile on the plugin path imports as a Group built from that file, and exports as the gizmo class again (without its children, as Nuke writes it). The plugin path, searched in order:$OPENCOMP_PLUGIN_PATH,~/.opencomp/gizmos,$NUKE_PATH,~/.nuke(with sub-folders). Gizmos found there also appear in the Tab menu. - User knobs (
addUserKnob) on any node are shown on their own tabs in Properties, keep their values and animation, and are written back. Link knobs follow their target. - Expressions and Tcl. Knob expressions (including
parent.,input0.and node-name references) and the Tcl that Nuke scripts use are evaluated.[python ...]calls go to thenukePython module. - Several views. A script with views (for example left and right) keeps them: the views and their colours are read from the Root settings, and a number, colour or checkbox knob with per-view values (
{default left 1 right 2}) imports with those values. In Properties, Split off and Unsplit beside a knob make or remove a per-view value. The values are written back to the.nk. - Precomp. A Precomp reads its own
.nkfile; its contents are not written into the parent script. - Roto and Tracker. Classic Roto bezier shapes (with feather and animation) and Tracker4 track tables import. Paint strokes and some per-shape attributes do not; the original shape text is kept and written back.
- BlinkScript kernels import with their source and parameter values (see BlinkScript and OFX). OFX nodes import when the plugin is installed. Read and Write nodes for movies keep Nuke's
mov64knob names, so movie settings survive a round trip (see Movies and web formats).
Round trips
Import, export and import again gives the same graph. Unsupported nodes, unknown knobs and the original Root settings are carried through, so a script can go Nuke → Oink → Nuke without losing what Oink does not understand.