Knob Types
This monster of a page presents all the knobs a NUKE Op is capable of creating, both by their ID and usage area. For a great example of most of them, check out the KnobParade example. The Knobs Introduction covers a number of factors to take into account when creating instances of these knobs.
Knobs By ID
Knobs By Type & Call
Abstract Numeric Data
The base form of knobs, these are useful for storing any form of data without implying a particular usage. Many more specialized knobs inherit from these base classes, in particular Array_knob.
Int_knob
Stores: int
Proxy adaptive: no
Notes: Presents just a numeric input box. No slider presented by default, animation menu in right-click context only.
Float_knob
Stores: float or double
Proxy adaptive: no
Notes: Both float and double varieties available. Presents a numeric input box, linear slider, and animation menu button.
Double_knob
Stores: double
Proxy adaptive: no
Notes: Same as calling
Float_knob with a double pointer. Essentially obsolete, but still usable.
UV_knob
Stores: 2 floats or doubles as array
Proxy adaptive: no
Notes: Presents two numeric input boxes, with hardcoded ‘u’ and ‘v’ sub-labels, plus an animation menu button. If you’re looking to get arbitrary sub-labels, you could use a combination of two instances of
Float_knob (with sliders and startline switched off) and an initial
Text_knob.
Array_knob
Stores: ConvolveArray (as provided by Convolve.h) storing an arbitrary width and height matrix of floats
Proxy adaptive: no
Notes: ConvolveArray contains methods for sizing the array. It can also be sized dynamically on creation by passing values in a ‘from_script’ fashion. For example, if you create the KnobParade example passing ‘Array_knob { { 0 1 2 } { 3 4 5 } }’ you’ll get an array knob of 3x2, with the appropriate values filled in. See your install’s toolbars.py (found in your nukescripts directory) to see how a Python panel script is used to provide the dynamic sizing on node creation for the Matrix entry.
MultiInt_knob
Stores: Arbitrary number of ints as array
Proxy adaptive: no
Notes: Takes the array dimension as an argument on construction. As with
Int_knob, it has numerical entry boxes and the animation menu in right-click context only.
MultiFloat_knob
Stores: Arbitrary number of doubles or floats as array
Proxy adaptive: no
Notes: Takes the array dimension as an argument on construction. Presents numerical entry boxes for each member, a linear slider, and animation menu button.
Color
Color knobs, as you might suspect from the name, allow storage and present interfaces enabling data to be treated as colors.
Color_knob
Stores: 3 doubles or floats as array
Proxy adaptive: no
Notes: Stores color values at either double or float precision. Initially shows a single entry box and slider, a button to split to 3 entry boxes, a button to pop up the NUKE color wheel, and a swatch showing the current color plus an eyedropper for sampling. The color swatch is looked up through the root monitor LUT to present an interface representation in a familiar color space.
AColor_knob
Stores: 4 doubles or floats as array
Proxy adaptive: no
Notes: As with
Color_knob, but stores and allows editing of a fourth value, representing alpha. Alpha is not represented in the swatch.
ColorChip_knob
Stores: unsigned int
Proxy adaptive: no
Notes: Presents a button which pops up the NUKE color wheel when clicked. Stores selected color bytes as rrggbb00. Generally used for allowing selection of interface colors. To get floating point equivalent (unpack the stored color), use from_sRGB().
String
String knobs present a variety of interfaces to the lowly char* pointer or std::string.
String_knob
Stores: char* or std::string
Proxy adaptive: no
Notes: Single line text field, either as a char* or a std::string.
File_knob
Stores: char*
Proxy adaptive: no
Notes: As with
String_knob, except no std::string option. Presents a string plus a button which launches the NUKE file browser. Alternatively, you can supply a FileKnob_Type to filter the files shown as per the default or customized rules.
Cached_File_knob
Stores: char*
Proxy adaptive: no
Notes: As with
File_knob, adding a dropdown which, depending on setting, allows NUKE to locally cache files on a network storage device.
Read_File_knob
Stores: char* or std::string
Proxy adaptive: no
Notes: As with
File_knob, adding a std::string option and requiring implementation of ReadFileKnobOwner. Not generally recommended (due to complexity of implementation), but may be useful in more esoteric situations.
Write_File_knob
Stores: char* or std::string
Proxy adaptive: no
Notes: As with
File_knob, adding a std::string option and dual storage which switches depending on the current proxy mode.
MultiLine_String_knob
Stores: char*
Proxy adaptive: no
Notes: A text field for multiple lines of text, including scroll bars.
Password_knob
Stores: char*
Proxy adaptive: no
Notes: Similar to
String_knob, without std::string implementation, and displaying a bullet character for every text element entered. Note that this stores plain text, so it is generally advisable for use in Python panels and other transitional implementations, as opposed to NDK based Ops.
Selection
Checkboxes and more.
Bitmask_knob
Stores: unsigned int
Proxy adaptive: no
Notes: A series of labelled checkboxes. Each checkbox sets one bit in the output integer (checkbox 1 sets bit 1, checkbox 2 sets bit 2, and so on). Pass a static const char* const for the labels themselves. Querying values is achieved by defining field bits then ANDing them with the int. Be wary of labels such as ‘r’, ‘g’, or ‘b’ as you’re liable to end up with unexpected label coloring.
Bool_knob
Stores: bool
Proxy adaptive: no
Notes: A single checkbox with a label to the right, and no new line by default. Be wary of labels such as ‘r’, ‘g’, or ‘b’ as you’re liable to end up with unexpected label coloring.
Lists
Presenting arbitrary data in a tidy, accessible form.
List_knob
Stores: std::vector of std::vectors of std::strings
Proxy adaptive: no
Notes: The outer vector defines each row and the inner vector a series of string columns. Generally
Table_knob is a better option.
Table_knob
Stores: Manages own storage
Proxy adaptive: no
Notes: Presents an editable table supporting a variety of entry types. The interface is managed using TableKnobI.h methods.
SceneView_Knob
Stores: Manages own storage
Proxy adaptive: no
Notes: Presents a heirachial tree of items with user-selectable selection state. The interface is managed using SceneView_KnobI.h methods.
Channels
Channel and ChannelSet selection lists.
ChannelSet_knob
Stores: ChannelSet (as defined in ChannelSet.h)
Proxy adaptive: no
Notes: Presents a dropdown list of the current channelsets in the script with those not in the incoming stream in the ‘other’ sub menu. Also offers a ‘new’ entry to allow the creation of new channel sets.
ChannelMask_knob
Stores: ChannelSet (as defined in ChannelSet.h)
Proxy adaptive: no
Notes: Same as
ChannelSet_knob. A legacy knob, we recommend using the ChannelSet variety instead.
Channel_knob
Stores: 1 to 4 Channels (as defined in Channel.h) as an array
Proxy adaptive: no
Notes: Presents a dropdown list of the current channels in the script, plus a ‘none’ entry and ‘new’ entry, allowing the creation of extra channels.
Views
Access multiple views.
OneView_knob
Stores: int
Proxy adaptive: no
Notes: Presents a single selection dropdown list of the current views present in the script. The int stored can be related to the view names (and indeed, used to initialise the int as desired) using the outputContext() structure’s view related methods. Views are numbered from 0, where 0 is a special case ‘default’ view which is used as parent storage for all unsplit knobs.
MultiView_knob
Stores: std::set of ints
Proxy adaptive: no
Notes: Presents a multi-selection dropdown list of the current views present in the script. The ints stored in the std::set can be related to the view names (and indeed, used to initialize the int as desired) using the outputContext() structure’s view related methods. Views are numbered from 0, where 0 is a special case ‘default’ view which is used as parent storage for all unsplit knobs.
ViewView_knob
Stores: std::set of std::pairs of an int with an int
Proxy adaptive: no
Notes: Presents a ‘patch bay’ type interface allowing the user to specify a relationship between pairs of views. The ints stored in the std::pairs can be related to the view names (and indeed, used to initialise the int as desired) using the outputContext() structure’s view related methods. Views are numbered from 0, where 0 is a special case ‘default’ view which is used as parent storage for all unsplit knobs.
ViewPair_knob
Stores: std::pair of an int with an int
Proxy adaptive: no
Notes: Presents a pair of single select dropdown lists of the current views within the script, and represents a relationship between the two views. The ints stored in the std::pair can be related to the view names (and indeed, used to initialise the int as desired) using the outputContext() structure’s view related methods. Views are numbered from 0, where 0 is a special case ‘default’ view which is used as parent storage for all unsplit knobs.
Layout
Knobs enabling you to lay out your controls in a sensible and accessible fashion.
Tab_knob
Stores: No data storage
Proxy adaptive: no
Notes: Starts a new Tab in the parameter panel and resets BeginGroup hierarchy to zero. By default, without an initial Tab declaration, the first tab on a node inherits its name from the node itself. Declaring a name up front, before any other knobs, simply renames the first tab - it does not create a new tab. Tab_knobs allow controls to be grouped according to logical delineation. It’s generally best practise to put the most commonly used controls up front and lesser used ones on subsequent tabs. For the lesser used knobs that still need to be altered within the context of the primary controls, the
BeginGroup/EndGroup or
BeginClosedGroup/EndGroup knobs may be a better choice. If you have the situation within a page where there’s a set of controls which can be divided into logical groups, the
BeginTabGroup/EndTabGroup knob may be applicable.
BeginGroup/EndGroup
Stores: No data storage
Proxy adaptive: no
Notes: BeginGroup and EndGroup wrap any intervening knobs in an open twirly (default behavior). This allows the user to spin the contents up or down to minimise the screen real estate used. They are generally recommended for more in depth control access (those controls not required for every Op application), for example knobs that are altered with reference to other knobs outside the group, but on the same tab. For knobs which are less frequently applied, the
BeginClosedGroup/EndGroup knob may be more useful, and for situations where the knobs in the group have no alteration requirement within the context of other controls (outside the group), see the
Tab_knob.
BeginClosedGroup/EndGroup
Stores: No data storage
Proxy adaptive: no
Notes: Similar to
BeginGroup/EndGroup, but presents wrapped knobs inside a twirly which is closed by default.
Text_knob
Stores: No data storage
Proxy adaptive: no
Notes: Presents as user defined text on the Properties panel, but does not start a new line by default. Note that this can be used between knobs by clearing the start line flag on the subsequent knob.
Named_Text_knob
Stores: No data storage
Proxy adaptive: no
Notes: Same as
Text_knob, but allows a name to be passed on creation, allowing the knob object to be accessed later.
Spacer
Stores: No data storage
Proxy adaptive: no
Notes: Presents as a empty horizontal gap between whatever knobs are on either side. In most circumstances, you’ll need to clear the start line flag on the subsequent knob to prevent it line feeding, negating any effect from the spacer itself.
Newline
Stores: No data storage
Proxy adaptive: no
Notes: Used to force a new line (line feed) for knobs that don’t do this by default (alternatively you can use the STARTLINE knob flag).
Divider
Stores: No data storage
Proxy adaptive: no
Notes: Used to split the controls into logical groupings, it presents a line drawn across the knob Properties panel and an optional text label.
Help_knob
Stores: No data storage
Proxy adaptive: no
Notes: Presents a button with a ? label, used to pop up a help line. Generic help info should go in the Op’s help text return, and knob specific help in the respective knob’s tooltip, but this can be useful in circumstances where you have a grouping of controls requiring extra explanation.
BeginTabGroup/EndTabGroup
Stores: No data storage
Proxy adaptive: no
Notes: Allows a specific region of a panel to be split into multiple tabs. Requires the use of
Tab_knob between the Begin and End calls to setup the set of tabs, with all knobs falling after a tab declaration appearing on that panel.
BeginExoGroup/EndExoGroup
Stores: No data storage
Proxy adaptive: no
Notes: Presents the wrapped knobs on every Tab of the Op’s Properties panel as an extra-tabular group. Does not provide a twirly (either open or closed), so this may need to be your first wrapped knob.
These knobs have no interface as such - they simply wrap the controls encompassed and present them on all tabs.
Specialist
Miscellaneous knobs, some very useful and some more esoteric.
LookupCurves_knob
Stores: LookupCurve (as defined by LookupCurves.h)
Proxy adaptive: no
Notes: Presents a curve interface with an arbitrary number of curves included. The curve editor interface can be flagged on construction as a particular type, to allow drawing of colored swatches and curves, or to alter curve behavior. Implementing and using such a knob can be a little more involved than most of the others covered thus far, and so both the KnobParade and ColorLookup examples provide an insight into this knob in action. The LookupCurve provides the core of the tool, as it’s constructed from a CurveDescription which defines the default curves, names, tooltips, and so on.
Histogram_knob
Stores: Histogram_Data (as defined by HistogramKnob.h)
Proxy adaptive: no
Notes: Presents a read only histogram graph interface with two sets of data (in most cases representing in and out). See the KnobParade example for a sample of how to populate the data structure. Note that this is the only knob which does not take ownership of the data pointer passed, and therefore requires a reference count decrement call in the Op destructor to allow the data to be freed when no longer in use.
Eyedropper_knob
Stores: 8 floats as an array
Proxy adaptive: no
Notes: Presents a color swatch button that activates an eye dropper color sampling interface operated using the standard NUKE sampling hotkeys. This allows both point and area sampling with the color swatch drawn in a monitor LUTed representation of the underlying stored value. The first 4 floats represent the color picked, and the second set of 4 represent the x, y, r, and t of the box from which the sample was taken.
Range_knob
Stores: An arbitrary number of doubles or floats as an array
Proxy adaptive: no
Notes: Presents a single slider along with an arbitrary number of numerical entry boxes. Note that the slider handles are unable to cross over each other, so the floats have to be sequential and sorted.
Keyer_knob
Stores: 4 doubles as an array
Proxy adaptive: no
Notes: Presents a trapezoid graph shape with corners defined by the data values. Used in the Keyer node and generally not recommended elsewhere.
Link_knob
Stores: No data storage
Proxy adaptive: no
Notes: Soft links to another node, identified by the name passed on construction. It presents panel and Viewer widgets from the soft linked knob, and is is generally used in NUKE to present knobs internal to a gizmo on its main Properties panel.
Ripple_knob
Stores: Manages internal data storage
Proxy adaptive: no
Notes: Presents a ripple keyframing interface as found in the Roto and RotoPaint nodes. It is used to define changes across a temporal range. The knob should be controlled using its interface header RippleKnobI.h.
Obsolete_knob
Stores: No data storage
Proxy adaptive: no
Notes: Obsolete_knob is a mechanism for changing the name and action of knobs. Please see
Versioning for an in depth discussion of its uses.
No interface presented.
GeoSelect_knob
Stores: Manages internal data storage
Proxy adaptive: no
Notes: Presents a button interface on the Viewer, and a series of selection based handles on 3D geometry. Creation of Geoselect_knobs is not recommended, however GeoOp’s inherit one automatically (assuming you chain the knob’s call back to the GeoOp parent). This can be accessed using the name “geo_select” and addressed using the interface defined in GeoSelectKnobI.h.
Python_knob
Stores: <dependent>
Proxy adaptive: no
Notes: The Python_knob allows a set of Python bindings to be made against the underlying c++ data. See the PythonGeo example for a sample of this in action.
Custom_knob
Stores: <dependent>
Proxy adaptive: <dependent>
Notes: Allows construction of user defined knobs. These are able to store arbitrary data and present Qt interfaces on the param panel and/or OpenGL widgets in the Viewer. See
Creating Custom Knobs for more information.