Houdini Main Changelogs
6.0.264 | Skinning surfaces (such as NURBs surfaces) will now properly respect the V Wrap parameter. |
Tue. April 8, 2003 | |
6.0.264 | Fixed bug where the Curve SOP would no longer snap consolidate to incoming geometry. |
Tue. April 8, 2003 | |
6.0.264 | Fixed bug where the Curve SOP would no longer snap consolidate to incoming geometry. |
Tue. April 8, 2003 | |
6.0.264 | Fixed bug where the Curve SOP would no longer snap consolidate to incoming geometry. |
Tue. April 8, 2003 | |
6.0.264 | Fixed bug where the Curve SOP would no longer snap consolidate to incoming geometry. |
Tue. April 8, 2003 | |
6.0.264 | Fixed bug where the Curve SOP would no longer snap consolidate to incoming geometry. |
Tue. April 8, 2003 | |
6.0.264 | Fixed problem where doing an Extract Contents operation on a subnet operator that matches its current definition contents would result in the extracted nodes being read-only, which in turn would prevent expressions from being updated properly, inputs being modified, and so on. |
Tue. April 8, 2003 | |
6.0.264 | Fixed problem where doing an Extract Contents operation on a subnet operator that matches its current definition contents would result in the extracted nodes being read-only, which in turn would prevent expressions from being updated properly, inputs being modified, and so on. |
Tue. April 8, 2003 | |
6.0.264 | Fixed problem where doing an Extract Contents operation on a subnet operator that matches its current definition contents would result in the extracted nodes being read-only, which in turn would prevent expressions from being updated properly, inputs being modified, and so on. |
Tue. April 8, 2003 | |
6.0.264 | Fixed problem where doing an Extract Contents operation on a subnet operator that matches its current definition contents would result in the extracted nodes being read-only, which in turn would prevent expressions from being updated properly, inputs being modified, and so on. |
Tue. April 8, 2003 | |
6.0.264 | Fixed problem where doing an Extract Contents operation on a subnet operator that matches its current definition contents would result in the extracted nodes being read-only, which in turn would prevent expressions from being updated properly, inputs being modified, and so on. |
Tue. April 8, 2003 | |
6.0.264 | Fixed problem where doing a "Create VOP Type From" operation could produce a VOP that generated bad code if the code contained tab characters (the tabs would be converted into the string "\t"). |
Tue. April 8, 2003 | |
6.0.264 | Fixed problem where doing a "Create VOP Type From" operation could produce a VOP that generated bad code if the code contained tab characters (the tabs would be converted into the string "\t"). |
Tue. April 8, 2003 | |
6.0.264 | Fixed problem where doing a "Create VOP Type From" operation could produce a VOP that generated bad code if the code contained tab characters (the tabs would be converted into the string "\t"). |
Tue. April 8, 2003 | |
6.0.264 | Fixed problem where doing a "Create VOP Type From" operation could produce a VOP that generated bad code if the code contained tab characters (the tabs would be converted into the string "\t"). |
Tue. April 8, 2003 | |
6.0.264 | Fixed problem where doing a "Create VOP Type From" operation could produce a VOP that generated bad code if the code contained tab characters (the tabs would be converted into the string "\t"). |
Tue. April 8, 2003 | |
6.0.263 | In the past, if a channel reference (ch() expression) referred to a parameter that was overridden by a chop, and the node that owns the parameter was not cooked, the channel reference would not correctly evaluate to the overrided value. This has been fixed. In simpler terms, CHOPs should cook properly in hscript now. |
Mon. April 7, 2003 | |
6.0.263 | In the past, if a channel reference (ch() expression) referred to a parameter that was overridden by a chop, and the node that owns the parameter was not cooked, the channel reference would not correctly evaluate to the overrided value. This has been fixed. In simpler terms, CHOPs should cook properly in hscript now. |
Mon. April 7, 2003 | |
6.0.263 | In the past, if a channel reference (ch() expression) referred to a parameter that was overridden by a chop, and the node that owns the parameter was not cooked, the channel reference would not correctly evaluate to the overrided value. This has been fixed. In simpler terms, CHOPs should cook properly in hscript now. |
Mon. April 7, 2003 | |
6.0.263 | In the past, if a channel reference (ch() expression) referred to a parameter that was overridden by a chop, and the node that owns the parameter was not cooked, the channel reference would not correctly evaluate to the overrided value. This has been fixed. In simpler terms, CHOPs should cook properly in hscript now. |
Mon. April 7, 2003 | |
6.0.263 | In the past, if a channel reference (ch() expression) referred to a parameter that was overridden by a chop, and the node that owns the parameter was not cooked, the channel reference would not correctly evaluate to the overrided value. This has been fixed. In simpler terms, CHOPs should cook properly in hscript now. |
Mon. April 7, 2003 | |
6.0.263 | The command chkey -t 0 -F 'raw()' /o/ring?/tz,rx Will work once again. |
Mon. April 7, 2003 | |
6.0.263 | The command chkey -t 0 -F 'raw()' /o/ring?/tz,rx Will work once again. |
Mon. April 7, 2003 | |
6.0.263 | The command chkey -t 0 -F 'raw()' /o/ring?/tz,rx Will work once again. |
Mon. April 7, 2003 | |
6.0.263 | The command chkey -t 0 -F 'raw()' /o/ring?/tz,rx Will work once again. |
Mon. April 7, 2003 |