Fixed a bug where Parameter VOPs inside subnets would not have their proper pragmas output to the VFL code. This resulted in badly defined parameters when a VOPNET was used to "Create Context Operator Type". Also, we now generate our VFL code such that the parameters in the operator type resulting from this operation match the order of the parameters specified in the VOPNET.

Fixed a bug where Parameter VOPs inside subnets would not have their proper pragmas output to the VFL code. This resulted in badly defined parameters when a VOPNET was used to "Create Context Operator Type". Also, we now generate our VFL code such that the parameters in the operator type resulting from this operation match the order of the parameters specified in the VOPNET.

Fixed a bug where Parameter VOPs inside subnets would not have their proper pragmas output to the VFL code. This resulted in badly defined parameters when a VOPNET was used to "Create Context Operator Type". Also, we now generate our VFL code such that the parameters in the operator type resulting from this operation match the order of the parameters specified in the VOPNET.

Fixed a bug where Parameter VOPs inside subnets would not have their proper pragmas output to the VFL code. This resulted in badly defined parameters when a VOPNET was used to "Create Context Operator Type". Also, we now generate our VFL code such that the parameters in the operator type resulting from this operation match the order of the parameters specified in the VOPNET.

Fixed a bug where Parameter VOPs inside subnets would not have their proper pragmas output to the VFL code. This resulted in badly defined parameters when a VOPNET was used to "Create Context Operator Type". Also, we now generate our VFL code such that the parameters in the operator type resulting from this operation match the order of the parameters specified in the VOPNET.

Fixed a bug where connections to the inputs of Parameter VOPs could be lost when a hip file was reloaded.

Fixed a bug where connections to the inputs of Parameter VOPs could be lost when a hip file was reloaded.

Fixed a bug where connections to the inputs of Parameter VOPs could be lost when a hip file was reloaded.

Fixed a bug where connections to the inputs of Parameter VOPs could be lost when a hip file was reloaded.

Fixed a bug where connections to the inputs of Parameter VOPs could be lost when a hip file was reloaded.

When the opls command was run on certain patterns, the output was ambiguous. For example,

hscript -> opcf /obj hscript -> opls -d */* file1 file1 box1 subdivid1 box1

Would list the names of all the SOPs for all objects. The problem previously was that there was no way to determine which SOPs belonged to which object. The current method will use the pattern given to the command to determine how to print out the names. The new output would look like:

hscript -> opcf /obj hscript -> opls -d */* cam1/file1 light1/file1 geo1/box1 geo1/subdivid1 geo2/box1

When the opls command was run on certain patterns, the output was ambiguous. For example,

hscript -> opcf /obj hscript -> opls -d */* file1 file1 box1 subdivid1 box1

Would list the names of all the SOPs for all objects. The problem previously was that there was no way to determine which SOPs belonged to which object. The current method will use the pattern given to the command to determine how to print out the names. The new output would look like:

hscript -> opcf /obj hscript -> opls -d */* cam1/file1 light1/file1 geo1/box1 geo1/subdivid1 geo2/box1

When the opls command was run on certain patterns, the output was ambiguous. For example,

hscript -> opcf /obj hscript -> opls -d */* file1 file1 box1 subdivid1 box1

Would list the names of all the SOPs for all objects. The problem previously was that there was no way to determine which SOPs belonged to which object. The current method will use the pattern given to the command to determine how to print out the names. The new output would look like:

hscript -> opcf /obj hscript -> opls -d */* cam1/file1 light1/file1 geo1/box1 geo1/subdivid1 geo2/box1

When the opls command was run on certain patterns, the output was ambiguous. For example,

hscript -> opcf /obj hscript -> opls -d */* file1 file1 box1 subdivid1 box1

Would list the names of all the SOPs for all objects. The problem previously was that there was no way to determine which SOPs belonged to which object. The current method will use the pattern given to the command to determine how to print out the names. The new output would look like:

hscript -> opcf /obj hscript -> opls -d */* cam1/file1 light1/file1 geo1/box1 geo1/subdivid1 geo2/box1

When the opls command was run on certain patterns, the output was ambiguous. For example,

hscript -> opcf /obj hscript -> opls -d */* file1 file1 box1 subdivid1 box1

Would list the names of all the SOPs for all objects. The problem previously was that there was no way to determine which SOPs belonged to which object. The current method will use the pattern given to the command to determine how to print out the names. The new output would look like:

hscript -> opcf /obj hscript -> opls -d */* cam1/file1 light1/file1 geo1/box1 geo1/subdivid1 geo2/box1

There is a new pragma in VEX to define a string parameter which represents a path to an operator in Houdini. This is also accessible through the Type Properties dialog for any operator which allows parameters to be defined. For example:

#pragma hint nullobject oppath obj/null #pragma hint cookpop oppath pop

The first pragma would provide a string gadget with a + button for the tree chooser. The tree chooser would only allow selection of null objects. The second pragma would only allow selection of POPs. Please see the VEX compiler notes for more information.

There is a new pragma in VEX to define a string parameter which represents a path to an operator in Houdini. This is also accessible through the Type Properties dialog for any operator which allows parameters to be defined. For example:

#pragma hint nullobject oppath obj/null #pragma hint cookpop oppath pop

The first pragma would provide a string gadget with a + button for the tree chooser. The tree chooser would only allow selection of null objects. The second pragma would only allow selection of POPs. Please see the VEX compiler notes for more information.

There is a new pragma in VEX to define a string parameter which represents a path to an operator in Houdini. This is also accessible through the Type Properties dialog for any operator which allows parameters to be defined. For example:

#pragma hint nullobject oppath obj/null #pragma hint cookpop oppath pop

The first pragma would provide a string gadget with a + button for the tree chooser. The tree chooser would only allow selection of null objects. The second pragma would only allow selection of POPs. Please see the VEX compiler notes for more information.

There is a new pragma in VEX to define a string parameter which represents a path to an operator in Houdini. This is also accessible through the Type Properties dialog for any operator which allows parameters to be defined. For example:

#pragma hint nullobject oppath obj/null #pragma hint cookpop oppath pop

The first pragma would provide a string gadget with a + button for the tree chooser. The tree chooser would only allow selection of null objects. The second pragma would only allow selection of POPs. Please see the VEX compiler notes for more information.