|On this page|
By itself, this nodes doesn’t do anything. You must add spare parameters corresponding to attributes on prims in the scene graph tree. Then when you edit the spare parameters, the node authors equivalent changes to the referenced attributes.
How to ¶
In Primitives, set the path(s) to the primitive(s) you want to the edit.
Click Edit Properties.
This opens the Edit Parameter Interface window with the From USD tab selected in the source pane on the left.
Find the prim you want to edit (or a prim of the same type). Click the plus button to expand it to show the properties as child items.
(The specific primitive you drag the property out of does not matter. It doesn’t affect which primitives this node changes. The node only uses the property name. This node always and only edits the prims selected in Primitives.)
Drag the property from the source tree on the left into the Existing parameters tree in the center. Drop it below “Primitive Path (
primpath)” and above “Action (
Dropping the item in the parameter tree will actually create two parameters: a “control” pop-up menu containing options for how to author the property, and a parameter for setting the parameter value. (For example, if you drop the
sizeattribute from a
Cubeprimitive, it will create both
Control pop-up menus ¶
For each prim selected in the Primitives parameter, the node will look for properties with the same names as the properties you created spare parameters for. This node will only author properties on selected primitives if it has a matching parameter, and the control menu is set to write to the property.
So technically you have a single Edit Properties node that applies to prims of many different types, with a long list of parameters where each parameter applies to only a few of the selected prims. You may want to avoid doing this, however, since it might be confusing to other people trying to understand your network.
If you make a useful editing interface you want to share, you can turn an Edit Properties node instance into a LOP digital asset. Right-click the node in the network editor and choose Create digital asset. The spare parameters become the digital asset’s parameter interface, and the node functions the same way, but as an asset that can be shared and versioned.
Once you convert an Edit Properties node to a digital asset, you can’t add more spare parameters to an instance of the asset edit more properties. The asset only looks at its “baked in” parameters, and ignores spare parameters.
The USD attribute name is stored on the spare parameters as tag data.
In any parameter setting an attribute value, you can use the following local variables:
The total number of primitives being modified by this node.
Index of the primitive being modified. This value goes from
The path of the primitive being modified.
Custom properties that are commonly added to primitives but which are not part of any USD schema can be specified in a file named
EditPropertiesCustom.usdaanywhere in your
HOUDINI_PATH. This file describes a USD stage using any standard USD composition rules. The
/customprimitive and all of its descendant primitives and their properties will appear in the Edit Parameter Interface window on the
USDtab, under the
A node of this type or any digital assets derived from this node type can also optionally have parameters that validate the node’s parameters and trigger warnings or errors if requirements are not met. As an example of this technique, the Render Settings LOP has validation parameter that trigger a warning if the node is asked to create a new primitive that is not inside the
/Renderbranch of the scene graph hierarchy (as mandated by the USD Render Setting specification). To use this feature, two parameters are used:
An ordered menu indicating whether the validation message should be presented as a Message, Warning, or Error (using the values
The message to be presented to the user. If this parameter returns an empty string, no message is added to the node.
This node belongs to a class of nodes that create or edit USD prims directly. These nodes operate in Create mode or Edit mode. This is controlled by a Create primitives checkbox or a Create/Edit popup menu. In create mode, the node creates new prims. In edit mode, the node changes the attributes on an existing prim. The Edit mode has two variations. Edit will not modify primitives which have a
houdini:editable attribute set to
false. Force edit will modify a primitive regardless of the existence or value of this attribute. This attribute can be set on a primitive using the Configure Primitives LOP.
Parameters that correspond to a USD attribute have a pop-up menu to the left that controls how the node authors the attribute.
In addition to that, any connectable USD attributes (i.e., the ones in the
inputs: namespace) will have menu items that allow disconnecting them from their sources.
Pop-up menu item
Set or Create
Sets the attribute to the given value, whether it previously existed or not.
Set If Exists
Only set the attribute to the given value if it previously existed.
Use this mode to make sure an attribute is only set on primitives of the correct type. For example, only
Makes the attribute appear to not exist, so it takes on its default value. (If the attribute doesn’t already exist on the prim, this does nothing.)
Deletes the attribute input connection to its source. Input connections take precedence over attribute values, so disconnecting an input allows the attribute value to take effect.
Ignore this parameter, don’t create or change the attribute in any way.
Cooking this node can generate many USD time samples, rather than just a single time sample at the current time. This can be equivalent to having a Cache LOP following this node, but it will evaluate much faster, and does not cache data from any other nodes. This allows animated data to be authored to USD without introducing a node time dependency which would then cause all following nodes to also be time dependent. This can vastly improve playback performance of some LOP Networks.
In all sampling modes, if a parameter on this node does not vary with time, and does not rely on other time sampled data from the stage, only a single default value will be generated in USD for the corresponding attribute. USD time samples are only generated for parameters that may vary over time.
Sample Current Frame
A single time sample will be generated for the current time.
Sample Frame Range If Input Is Not Time Dependent
If the input to this node is time dependent, this node behaves as if it is in
Sample current frame mode. Otherwise it behaves as if it is in
Sample frame range mode.
Sample Frame Range
The Start/End/Inc parameter is used to generate multiple times at which this node’s parameters are evaluated, and a USD time sample is created for each attribute at each one of these times.
When the Sampling behavior is
Sample frame range, this parameter controls the number and spacing of base time samples to be generated by this node. The default values of this parameter are
@ropinc. These values correspond to the start, end, and step size of the global Houdini animation settings when interacting with Houdini. When using a ROP node to generate a range of frames, these values correspond to the start, end, and increment values specified on the ROP node being executed. This default ensures that a USD file written to disk will contain time samples for exactly the frame range requested by the ROP (regardless of the Houdini animation settings).
For each primary sample generated by this node, these parameters can cuase additional samples to be generated aroudn that primary sample time. This is most often used to ensure that accurate data exists at exactly the camera shutter open and close times, as well as at the primary sample time.
Controls the method used to specify the shutter open and close times relative to the primary sample times.
The Shutter open/close parameter values provide exact offset values relative to the primary sample time.
Use Camera Prim
The Camera prim parameter provides the scene graph path of a camera primitive from which the shutter open and close times are extracted to provide the offset values relative to the primary time sample.
When the Shutter mode is
Specify Manually, these two offset values are added to the primary sample time to indicate the shutter open and close times. The open time should be less than or equal to zero, and the close time should be greater than or equal to zero.
Scene graph path of a camera prim on the input node’s stage. The shutter open and close attribute values are read from this primitive.
The number of subframe samples to create for each primary sample. These samples are evenly distributed between the shutter open and close times. Note that such an even distribution may or may not create a sample at exactly the primary sample time.
Always Include Frame Sample
Enable this option to force a sample to be created at exactly the primary sample time. If the Samples values together with the shutter open and close times already place a sample at the primary sample time, turning on this option will have no effect. Otherwise, this option will cause an addition sample to be added. This means that the actual number of samples per primary sample may in fact be one more than the number specified in the Samples parameter.
Opens the Edit Parameter Interface window with the From USD tab selected in the source pane on the left.
Whether this node should create new prims, or edit existing prims. In addition, the
Force Edit option can be chosen to cause this node to ignore the
houdini:editable attribute on prims, and always edit the specified attributes. This is in contrast to the
Edit mode which will trigger a warning and not set attributes on prims with the
houdini:editable attribute set to
In create mode, this lets you control where in the scene graph to create the prim(s).
The default is usually
/$OS. This creates a primitive at the root level with the same name as the node (for example,
/tube1). This is a useful default for preventing naming conflicts, but terrible for organization. You should try to remember to change the Primitive path to a better value when you create prims.
For example, instead of naming models after the node that created them, you might want to name them after the geometry inside, and organize them under a
The “Create primitives” section contains basic controls for how to create the new prim(s).
In edit mode, the node has a Primitive pattern parameter. This lets you specify the prim(s) the node should operate on. You can click the select button beside the text box to select the primitives from the scene graph tree. You can also use primitive patterns for advanced matching, including matching all prims in a collection.
Initialize Parameters For Edit
In edit mode, changes the state of all control menu parameters to
Do Nothing, so that this node will not apply any changes. Also grabs the current values of each property from the first Primitives match, and sets the values of the corresponding parameters to match. This means that changing any parameter’s control menu to
Set or Create mode will set the property to its current value, making it easier to apply changes to an existing value rather than setting a brand new value.
This section only appears when the node is creating primitives.
If you want to create a new cube primitive at
/world/objects/cube1on an empty stage: Set Primitive Specifier to “Define”, and the Parent Primitive Type to “Xform”.
If you want to override the radius of a sphere at
/world/objects/sphere1: Set Primitive Specifier to “Over”, and the Parent Primitive Type to None. This makes sure the primitive types of any existing ancestor prims are not be modified by this node.
The number of primitives to create.
Set all created prims to have this kind.
The USD operator to use when creating the new prims.
Authors a completely new prim. Use this if you want to create a brand new prim or replace an existing prim.
Authors an override of an existing prim. Attributes not explicitly authored on this prim will get their values from the existing prim on the lower layer.
Define a primitive class. This is usually not necessary unless you are doing deep USD magic.
If the Specifier is
Over, this parameter will cause some ancestor primitives to be authored with a specifier of
Class. This makes it easy to create an
Define within a
Class without having to use two separate nodes. When the Specifier is
Class, this parameter is disabled because the entire primitive hierarchy is already authored as
Parent Primitive Type
If any parents of a path in Primitive paths do not exist, this node will automatically create them. In this case, it will create parent nodes of this type.