Skip to content

doc node pointer

Jed Smith edited this page Dec 27, 2021 · 5 revisions

A node which automatically reconnects itself to a target. Lightweight, efficient, and self-contained.

You can use the Create button to create an anchor node with the specified target name. Pointer Demo 1

If no target name is entered, you will be prompted to type a name. Note the color of the Pointer is taken from the topnode. Pointer Demo 1

You can also use an existing node as a target (press Set with the target node selected), or create one manually. Pointer Demo 1

Context

There are certain circumstances where you need access to one input to a Nuke script in many places.

Maybe you read in a plate, create a denoise, and need to access this denoise precomp in a few different places in your script. One for paint work, one for extraction work, one for a regrain at the end of your comp.

Maybe you have a set of 4 different rotos for different part of your plate, and you are working on an extraction. You need to have access to one roto in 10 different parts of your extraction comp.

One way of working is to duplicate that source multiple times in the script. This is not a procedural way of working and is bad. For read nodes it is less efficient, and creates a situation where you have many copies of the same thing in the script that you need to manage. For example if you version up one of your nodes, did you remember to version up the others? Or do you now have 1 that is the right version and two other copies that are an older version? This can get out of hand.

For Rotos especially, duplicating copies around the script is very inneficient, and can quickly slow a script to a crawl.

Usage

  • Create a Pointer node.
    Pointer Node UI
  • Create a target.
    1. Type a unique+descriptive name in the target text knob.
    2. Select the node you want to place the target on.
    3. Click Create. A dot node is created. The Pointer node will always be connected to this target.
  • If no target name is entered you will get a popup window asking you for a name.
  • The node will be automatically colored based on the topnode color of the target node.
  • You can also use an existing node as the target if you select any node and press "Set". This sets the target knob to the selected node name.

The Pointer node knobs:

  • target: The node name to which this pointer will be anchored.
  • Create: Creates a target node with the specified target name. This knob self-destructs to keep the Pointer node lightweight.
  • Set: Sets the selected node as the target.
  • Zoom: Zooms the DAG to the anchor node.

Caution

Generally speaking, you should only anchor an input to your script. A read node, a camera, a geometry, a roto, etc.

If you are trying to anchor to some location in the middle of your script, you are not working procedurally and you are probably making a horrible mistake which is going to cause pain and suffering to someone. Either you in the near future, or someone else who is taking over your script, or some poor stereo conversion artist who has to figure out your mess later down the line.

Work responsibly! The first and most important rule of efficient comping is DO ONE THING IN ONE PLACE.

Dev Notes

Inspiration

I built the Anchor Pointer system inspired by Adrian Pueyo and Alexey Kuchinski's Stamps tool. After using it for a while I found it to be too over-engineered and heavy. I wanted something way lighter, simpler, and more efficient.

I struggled for a while to find a way of automatically reconnecting nodes with hidden inputs when pasting.

Previously I had been using the hidden_input_handler.py, which overrides the built-in cut/copy/paste functions to achieve this. This always bothered me since it's pretty extreme overriding default functions in this way.

A Saga of knobChanged callbacks

Of course there is the obvious solution, which relies on a python knobChanged callback in the node to reconnect itself to it's target. This is the approach Stamps uses.

Over the years I have optimistically used this approach for many things and every time it ends up in pain and suffering. With production sized Nuke scripts, knobChanged callbacks are always dangerous, especially for nodes that have many copies of each other.

KnobChanged callbacks cause slow scripts.

There are workarounds you can use like putting the knobChanged callback on a node inside of a group, so that the callback only fires when the knob in question is changed, instead of every time the node's selection state or node graph position changes. It's still dangerous though.

Is there another way?

The onCreate callback might be another option. This only fires when the node is initially created, or is re-created like when you cut and paste the node. Unfortunately there is a bug in Nuke which prevents the 0th input from connecting in an onCreate callback.

After a whole lot of experimentation I found an interesting hack. There's a special knob autolabel. You can put a single line python expression in there to override how the node is displayed in the node graph. Stamps uses this to set the name of the anchor and stamp node to the tag of that set.

It turns out if you put a python expression in there that executes some code but doesn't return a string, it will still execute. And it executes after the node is created, so you have the ability to control the input connections. And the cool thing is it only executes once when drawing the node in the dag. I've done a couple tests with several hundred copies of a pointer and once they have all loaded it doesn't slow down the script. This is not the case with Stamps.