Knobs are the fundamentals of all user interface elements available to NUKE Ops. They provide mechanisms for user interaction in both the viewer and the param panels, along with storing and accessing data in the NUKE script file.
In previous sections we’ve come across various subsets of the knobs on offer and their capabilities. In this section we’ll take a look at the full range of built in knobs offered, their usage and the customisation options, before moving on to building custom knobs from scratch.
Knobs fall into 1 of 3 broad categories. Those that use data storage initialised in the operator itself (for example the standard set of data types such as Int_knob), those that use no data storage (for example Tab_knob and other layout knobs), and more complex and recent additions which manage their own internal data storage (for example Table_knob).
Using the first type involves declaring appropriate data storage as a member variable of the Op, initialising it in the Op constructor and then passing it by address on Knob creation. The member variable is subsequently synchronised with the interface value before multithreaded data access calls such as engine(). At other times the knob object itself can be accessed using knob(“<name>”), though keep in mind this should be done only from calls in the main thread. Note that the knob does not directly employ the variable passed for internal storage, rather it is used during the knobs call to set the default value and for synchronisation.
The second type is obviously pretty simple - simply call the appropriate knob constructor and you’re good to go.
Working with the final type is generally fairly specific to the knob in question, but normally follows the same basic form. All of these knobs have a ‘<knobname>I.h’ header file associated with them which provides the various methods that particular knob offers. Each of these uses a knob pointer dependent on class, which can be obtained using from the knob pointer using a knob-><knobname> call. Most of these knobs need to be configured on creation, so you’ll often need to use a snippet similar to the one following:
Knob* tableKnob = Table_knob(f, "Table_knob");
if (f.makeKnobs()) {
Table_KnobI* tableKnobI = tableKnob->tableKnob();
tableKnobI->addColumn("col1", "col1", Table_KnobI::FloatColumn, true);
tableKnobI->addColumn("col1", "col1", Table_KnobI::FloatColumn, true);
}
Here the Knob_Callback (named f) is used to figure out if the knobs call is in creation mode, and then only when in this mode is the Table_knob object manipulated.
All knobs, with the exception of one or two layout types, take a name char* on construction. This allows the knob to be both accessed later on via knob(<name>) calls, is used to identify the values written to and read from a NUKE script, and is used as the name with which to access the knob by NUKE’s various scripting language. An additional ‘label’ char* can be provided so that the interface panel can use a different string to the full name (generally for brevity). In the NUKE interface the name can be obtained by hovering over a control - the first entry on a tooltip is always a bold formatted name for that knob.
The name must be individual - naming multiple knobs the same thing on an Op will result in all sorts of weirdness, so don’t do it! Spaces may cause artists delimiting issues when addressing via scripting, so also not recommended. Most of NUKE’s other controls are named all lowercase, using an underscore word delimiter, so it’s generally worth following this convention to provide the easiest and most accessible interface to users. Labels also generally follow the lowercase convention, although with actual spaces where required.