Parameter VOP

The Ultimate Houdini node reference

Visit the Node Bible

To learn more, please log in or sign up for free to explore the Node Bible.
Write your awesome label here.

Parameter VOP

Note that the Parameter VOP Shares the same videos as the Bind VOP because they are very similar.

Write your awesome label here.
Write your awesome label here.

The Parameter VOP creates a user parameter which can be seen on the vop network container.  

Drag to resize

Summary:

The parameter VOP is great if there's a setting that you'd like to control in sops.  As an example, if you wanted to control the color of something in SOPs, you could create a parameter VOP and use it to make the color parameter show up in Sops!  Parameters cannot be animated within VOPs, however, promoting it with the Parameter VOP will allow you to edit things in sops.  If you ever decide to turn a vop network into an HDA (Houdini digital asset), then the parameters you promote in vops will become the node parameters which the user sees when utilizing the HDA later on.  If you're new to this whole process, then check out Houdini For The New Artist II.

Drag to resize

Main Parameters:


Name:

--  In VOPs, you have the internal name and the label.  The internal name is the name that gets used for calculating stuff and its what everything else references when it tries to find this parameter.  The label is what the user sees in SOPs.  This "Name" is basically what the parameter should be internally understood as.

Prefix:

--  This adds text before the name.  To see what this does, look at the output of the node and notice how the Prefix happens before the name when determining the internal name of the parameter.  In practice, this might be useful for organizational purposes.

Postfix:

--  Same thing as "prefix" except that the text gets added to the end of the name.

Label:

--  This label is what the user sees in SOPs when the parameter gets promoted.

Show Label:

--  If you turn this off, then there will not be a label next to the parameter in SOPs.  Not sure why you would want this off, but alas, it is possible.

Type:

---------------------------------------------

  This represents the Vex Data Type that the attribute represents.  Keep in mind that vex data types are specific to vex, and may be only applicable within vex applications.  In other words, these data types might not be the same thing as what you see across other, non-vex areas of Houdini.

  What's confusing about these data types at first is the fact that there may be multiple instances of the same data type.  As an example, you could define an incoming attribute as an "integer" or perhaps a "toggle integer."  Both represent integer numbers.  Here's the difference:  if you were to promote a regular integer value, it would show up in the parameter window as a number slider in sops.  However, if you were to promote a toggle integer, then this promoted value would appear as a checkbox.  In other words, this "vex data type" can be used to control which sort of parameter style that you'd like to use when exporting to the cvex context.  These extra flairs will only appear when you use the parameter VOP or set a bind VOP to Export Always/Export When Input is Connected.

Here is a brief summary of each data type option:

---------------------------------------------

--  Float (float) =  A number which is allowed to have a decimal place in its value.  May be positive or negative.

--  Integer (int) =  A number which is not allowed to have a decimal place in its value.  May be positive or negative.

--  Toggle (int) =  Same as integer above, except that this data gets tagged as a "toggle" which means that the intended use of this integer value is for turning parameters off or on.  If you promote this attribute using a parameter vop, then it will appear as a checkbox on the sop level.

--  Angle (float) = This creates a float parameter that goes from 0 to 1 by default.  This could represent normalized rotation values which might be used for the rotation of something.  (CAUTION:  There is currently a bug that causes Houdini to crash when you adjust the default value of this parameter, so watch out for that)

--  Logarithmic (float) =  This float value goes from 0 to 1 by default.  But there's a caveat.  As you adjust the slider, the beginning values go in very small increments.  As you reach the end of the slider, those increments get larger until you reach the max range.

--  2 Floats (vector 2) =  This creates a vector 2 data type.  This is a collection of two values represented by two parameter boxes.

--  3 Floats (vector) =  This creates a vector value.  A vector value is a collection of three floats.  The parameter shows up as three boxes where you manually input the number you want for each value.

--  Vector =  This is the same as 3 Floats.  The difference between this and what is mentioned above is unclear.

--  Normal = This is the same as what is mentioned above - that is a collection of three float values.  This might be used for situations where you are trying to define the normal value of something.  In practice, it's not clear how this is different than "Vector" or "3 Floats."

--  Point = This is vector data which may be intended for use when defining a point position.  In practice, it's unclear how this is any different than using the vector data types mentioned above.

--  Direction (vector) =  This is vector data which may be intended for situations where you want to describe the direction that something is going in.  In practice, it's unclear how this is any different than using the vector data types mentioned above.

--  4 Floats (vector4) =  This is useful for times when you want to define a collection of 4 float values.

--  4 Floats (Matrix) =  A Matrix is essentially a table of information which is described by a certain number of columns and rows.  With the 4 Floats Matrix, the matrix only contains one column of 4 values.  In practice, this is pretty much the same thing as a 4 Floats (vector 4) with the only difference being that the data type would technically be considered to be a matrix rather than a vector.  This may be applicable when using other vex functions which rely on parsing through matrix data rather than vector data.  This will also not appear as a promoted parameter.

--  9 Floats (Matrix3) =  This creates a 3x3 matrix (that is, 3 columns vertically 3 columns horizontally) which all contain float values.

--  16 Floats (Matrix4) = This creates a 4x4 matrix (that is, 4 columns vertically 4 columns horizontally) which all contain float values.

--  String (string) =  A string value is any value that can be represented as text.  As an example, a string value might equal the word "foo" rather than numbers.

--  File (string) = A string value that gets used for browsing files.  In the parameter window, you'll have the browse dialogue available

--  Image (string) =  A string value that gets used for browsing files. In the parameter window, you'll have the browse dialogue available

--  Geometry (string) = A string value that gets used for browsing files. In the parameter window, you'll have the browse dialogue available

--  Color (vector) =  A vector value which represents color.  In the parameter window, you'll see a color browser.

--  Color (vector4) = A vector value which represents color.  This also includes an alpha as the 4th component.  In the parameter window, you'll see a color browser.

--  BSDF (F) =  This data gets used for shading purposes, and it will not be visible if promoted.  

--  Dictionary (dict) =   A dictionary data type is organized by having a key and associated value.  This may get useful when using functions that parse through dictionary values.  It will not be visible if promoted.

--  Co-Shader (shader) =  This data gets used for building shading networks.  When promoted, it will create a string path which asks you for a path to another shader.

--  Surface (shader) =  This data gets used for building shading networks.  If promoted, it will not show you anything.

--  Displacement (shader) =  This data gets used for building shading networks.  If promoted, it will not show you anything.

--  Volume (shader) =  This data gets used for building shading networks. If promoted, it will not show you anything.

--  Float Array (float[]) =  An array is essentially a collection of values that's stored as one entry.  For more information about how to use arrays in vex, check out Vex Foundations II.  This particular array contains float values.  If promoted, it will not show you anything.

--  All additional arrays follow the format described above.  If you go with a string array, then all entries of the array will need to be strings.  If it's a vector 2 array, then each entry will need to be a vec2 value - and so-on, for each type of array.

--  Custom (struct) = There are various other "Vex data types" that are miscellaneous and not mentioned above.  These data types get used for very specific situations, and for more information on them, it's best to research their intended use individually.  The possible Custom data types include:  FloatRamp, ShaderLayer, ColorRamp, ShaderExports, FuzzySet, Mapper, DualRest, PxrLayer, DualRest4, WorkItemPool, WorkItem, PxrLMLayer, PxrManifold.


Drag to resize

Exporting/Contexts/Menus:


Use This Node to Set Parameter Attributes:

--  When creating multiple bind nodes which reference the same attribute, only one is allowed to set the attribute inside of VOPs.  The reason why this is the case is because it's sort of like defining @foo multiple times.  In other words, only one bind will be responsible for actually bringing in attribute "foo."  If another bind node tries to bring in "foo," then it will basically refer to the first bind that was used to bring in foo rather than going into sops and importing "foo" again.  

--  When you check on, "Use This Node to Set Parameter Attributes," you're basically saying, "I want this bind node to be the one that goes into SOPs to pick up the data."

--  VOPs will determine which parameter/bind node is dominant by looking at when it was made.  Remember, VOPs are just a way of coding vex.  So, if you define an attribute called @foo towards the top of the script, it will be primarily defined there unless you check this box on.

Use Own Export Context:

--  The user documentation does a very, very poor job at describing what "contexts" are and how this parameter is intended to be used.  To make your life easier, any time that the word "context" is being used, it's referring to where the information goes when it gets exported from vops.  So, if you were to use the "Surface" context, that refers to the "surface" portion of the shader that gets compiled when Mantra goes to think about it at render time.  If you created a point vop within sops and used a bind node there, it would export to the "cvex" context.  The "cvex" context basically allows the information to become a promoted parameter that you see in sops.

--  According to the docs, "When several Parameter or Bind VOPs have the same Parameter Name, some other node will determine export context. However, it may be desirable to have each Parameter VOP exporting in a different context. In such cases, setting this parameter will enable this node to specify own export context, independent of the primary definer node." 

--  What the documentation describes as its own, "export context" is also vague.  In practice, you might be able to use this when creating custom data for AOVs or perhaps when you want to export into multiple contexts while using the same binding name.

--  Long story short, when you check on "Use Own Export Context," you're saying, "hey bind node, even though there's another bind and/or parameter node with the same attribute name as you, I want you to export to a separate context that isn't pre-determined by the the other parameter/bind node."  If you'd like to know where I discovered this hidden, arcane knowledge, then check out this video link right here

Use Input Value If Not Bound:

--  This parameter, again, assumes that you are trying to shade and render something with Mantra.  Also, it's helpful to understand that anything which is "bound" to the current vex context, is basically any attribute that's already been brought in with a bind, global variables, or parameter vop. 

--  According to the docs, "If true, the VEX function parameter is checked to see if it is bound to an attribute in the current VEX context (e.g. point color). If not bound, the input value is is assigned to the VEX parameter. In a Surface VOP context, a VEX parameter is bound if the geometry being shaded has an attribute with the VEX parameter name."

--  In practice, I'm not quite sure how you use this setting or why.  If you have further knowledge that you're willing to share on the subject, e-mail me at tyler@cgforge.com, and I'll be happy to update this section with better info.

Has Corresponding Connector:

--  This seems to assume that you'll be shading when using the parameter VOP.  According to the docs, "If true, the shader node parameter defined by this Parameter VOP will also have a corresponding input connector, providing such shader nodes can have input and output connectors."  In practice, I have not seen this parameter used before, and it's fairly vague to me how it may be used.  Again, if you have better information, I would be happy to hear from you at tyler@cgforge.com 

Export:

--  This parameter will allow you to export data from the bind node.  The "context" is where the bind node will export the data to.  You can choose, "Never" "When Input is Connected" or "Always."  Keep in mind that there is a hidden syntax which will enable you to export data outside of this parameter.  If you name anything with the prefix "export_", then it will export the parameter.

Export in Context:

--  Contexts can basically be understood as "where the data goes."  If you made a VOP in sops, then the default of "cvex" is there.  Exporting to "cvex" basically allows you to promote whatever parameter you're working with to the SOP level.  If you're shading, then you may choose other contexts such as "Surface" "Displacement" or even a custom AOV.  These context names will get recognized by the render engine at render time, and used for shading calculations when compiled at render.  

Provide Menu:

--  This parameter is cool because it allows you to create a menu of choices instead of a string entry field or an integer slider.  This only becomes available if you set the data type to string or integer.

--  Menu From Items =  This works by specifying, "A list of pairs of strings."  That means you need two strings for one menu entry.  The first string is the parameter value if the menu item is chosen.  The send string string is the label that the user sees when they drop down the menu in SOPs.  "The strings are separated by spaces. If you want a value or label to contain a space, surround the item with double quotes."

--  Menu Script =  "A script that populates the generated menu. You can write the script in either Hscript or Python. We highly recommend using Python.  A Python script should generate a list (or tuple) of strings where the odd items are values and the even items are labels, for example:

--  ["10", "Light", "50", "Medium", "100", "Heavy"]

--  Houdini handles the Python script in an odd way: if the script field contains a single line, Houdini treats it as an expression and expects it to evaluate to a list. If it has multiple lines, Houdini treats it as a function body and it must end with a return statement:

result = []
for input_node in hou.pwd().inputs():
    result += [input_node.path(), input_node.name()]
return result

--  For Hscript, the script should print a space-separated list of the form:

echo "token1" "Label 1" "token2" "Label 2" ...

Invisible:

--  Do not show the parameter in the shader’s parameter interface. The parameter still exists and will be used to generate shader strings.

Horizontally Join to Next Parameter:

--  When the parameter is promoted, this parameter will be positioned horizontally to the next parameter.  It's a nice way to be artistic for once.

Drag to resize

Tags:

The user documentation has a pretty good description of what tags do, and it's worth reading.

""Tags" let you attach arbitrary key/value data to the parameter template. You can access this data using hou.ParmTemplate.tags(). Some tags are recognized and used by different parameter types. You can also use them to store your own per-parameter hidden data.

Tags are used by the 3D viewer to signal when a parameter should be treated as an OpenGL value. For example, attaching the "OpenGL → Diffuse" tag to a parameter on a material node makes the 3D viewer treat that parameter’s value as the diffuse color when displaying the surface.

--  The tags are listed in a table in the "Parameter description" sub-pane on the right, when you select a parameter from "Existing Parameters" list in the middle.

--  Click Built in tags below the tag table to choose from a tree of different tags recognized by Houdini, including the OpenGL tags.

--  Some parameters may have internal tags attached to them which store options for the parameter’s look and behavior. These internal tags are not editable in the tag list.

--  Tag names must be unique within each parameter.

--  You can use the Key-Value Dictionary parameter type to add a tag-like editing interface to your own digital assets."

Help:

--  The contents of the text field appear in the help browser when the user clicks the help button for a node of this operator type in the parameter editor.
This help can be HTML, or you can use a simple but powerful wiki format to create documentation that looks like the native Houdini help.