Houdini Main Changelogs
 |
6.0.204 | There is a new VEX function to intersect a ray against a 3d texture map. Please see the VEX documentation for more details. |
Fri. February 7, 2003 |
|
6.0.204 | There is a new VEX function to intersect a ray against a 3d texture map. Please see the VEX documentation for more details. |
Fri. February 7, 2003 |
|
6.0.204 | There is a new VEX function to intersect a ray against a 3d texture map. Please see the VEX documentation for more details. |
Fri. February 7, 2003 |
 |
6.0.204 | The CHOP PreTransform, when set to the "Object and Channel" channel name mode, will name the channels the absolute path, ie /obj/model/tx, rather than model/tx. This can be undone with a rename CHOP, or ignored, as /obj/model/tx will do the expected overrides. |
Fri. February 7, 2003 |
|
6.0.204 | The CHOP PreTransform, when set to the "Object and Channel" channel name mode, will name the channels the absolute path, ie /obj/model/tx, rather than model/tx. This can be undone with a rename CHOP, or ignored, as /obj/model/tx will do the expected overrides. |
Fri. February 7, 2003 |
|
6.0.204 | The CHOP PreTransform, when set to the "Object and Channel" channel name mode, will name the channels the absolute path, ie /obj/model/tx, rather than model/tx. This can be undone with a rename CHOP, or ignored, as /obj/model/tx will do the expected overrides. |
Fri. February 7, 2003 |
|
6.0.204 | The CHOP PreTransform, when set to the "Object and Channel" channel name mode, will name the channels the absolute path, ie /obj/model/tx, rather than model/tx. This can be undone with a rename CHOP, or ignored, as /obj/model/tx will do the expected overrides. |
Fri. February 7, 2003 |
|
6.0.204 | The CHOP PreTransform, when set to the "Object and Channel" channel name mode, will name the channels the absolute path, ie /obj/model/tx, rather than model/tx. This can be undone with a rename CHOP, or ignored, as /obj/model/tx will do the expected overrides. |
Fri. February 7, 2003 |
 |
6.0.204 | 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. |
Fri. February 7, 2003 |
|
6.0.204 | 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. |
Fri. February 7, 2003 |
|
6.0.204 | 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. |
Fri. February 7, 2003 |
|
6.0.204 | 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. |
Fri. February 7, 2003 |
|
6.0.204 | 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. |
Fri. February 7, 2003 |
|
6.0.204 | Fixed a bug where connections to the inputs of Parameter VOPs could be lost when a hip file was reloaded. |
Fri. February 7, 2003 |
|
6.0.204 | Fixed a bug where connections to the inputs of Parameter VOPs could be lost when a hip file was reloaded. |
Fri. February 7, 2003 |
|
6.0.204 | Fixed a bug where connections to the inputs of Parameter VOPs could be lost when a hip file was reloaded. |
Fri. February 7, 2003 |
|
6.0.204 | Fixed a bug where connections to the inputs of Parameter VOPs could be lost when a hip file was reloaded. |
Fri. February 7, 2003 |
|
6.0.204 | Fixed a bug where connections to the inputs of Parameter VOPs could be lost when a hip file was reloaded. |
Fri. February 7, 2003 |
 |
6.0.204 | The output of pattern expansion of the opls command is now different than previous versions. This potentially breaks existing scripts which rely on the previous behaviour. Please see the release notes for details. |
Fri. February 7, 2003 |
|
6.0.204 | The output of pattern expansion of the opls command is now different than previous versions. This potentially breaks existing scripts which rely on the previous behaviour. Please see the release notes for details. |
Fri. February 7, 2003 |
|
6.0.204 | The output of pattern expansion of the opls command is now different than previous versions. This potentially breaks existing scripts which rely on the previous behaviour. Please see the release notes for details. |
Fri. February 7, 2003 |
|
6.0.204 | The output of pattern expansion of the opls command is now different than previous versions. This potentially breaks existing scripts which rely on the previous behaviour. Please see the release notes for details. |
Fri. February 7, 2003 |
|
6.0.204 | The output of pattern expansion of the opls command is now different than previous versions. This potentially breaks existing scripts which rely on the previous behaviour. Please see the release notes for details. |
Fri. February 7, 2003 |
|
6.0.204 | 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 |
Fri. February 7, 2003 |
|
6.0.204 | 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 |
Fri. February 7, 2003 |