Houdini Main Changelogs
4.9.541 | Adding preferences for whether or not secure selection should be on by default at the sop and object levels. |
Thu. November 22, 2001 | |
4.9.541 | Transform state should no longer core dump in TOPs and should be functional. |
Thu. November 22, 2001 | |
4.9.541 | Transform state should no longer core dump in TOPs and should be functional. |
Thu. November 22, 2001 | |
4.9.541 | Transform state should no longer core dump in TOPs and should be functional. |
Thu. November 22, 2001 | |
4.9.541 | Transform state should no longer core dump in TOPs and should be functional. |
Thu. November 22, 2001 | |
4.9.541 | Transform state should no longer core dump in TOPs and should be functional. |
Thu. November 22, 2001 | |
4.9.541 | When using the Set Keyframe option in object-specific handle for Bone objects, it now only sets keyframes on channels that are specifc to the handle type. eg. Set Keyframe while right-clicking on the capture region handle will only set keyframes on the cregion parameters. |
Thu. November 22, 2001 | |
4.9.541 | When using the Set Keyframe option in object-specific handle for Bone objects, it now only sets keyframes on channels that are specifc to the handle type. eg. Set Keyframe while right-clicking on the capture region handle will only set keyframes on the cregion parameters. |
Thu. November 22, 2001 | |
4.9.541 | When using the Set Keyframe option in object-specific handle for Bone objects, it now only sets keyframes on channels that are specifc to the handle type. eg. Set Keyframe while right-clicking on the capture region handle will only set keyframes on the cregion parameters. |
Thu. November 22, 2001 | |
4.9.541 | When using the Set Keyframe option in object-specific handle for Bone objects, it now only sets keyframes on channels that are specifc to the handle type. eg. Set Keyframe while right-clicking on the capture region handle will only set keyframes on the cregion parameters. |
Thu. November 22, 2001 | |
4.9.541 | When using the Set Keyframe option in object-specific handle for Bone objects, it now only sets keyframes on channels that are specifc to the handle type. eg. Set Keyframe while right-clicking on the capture region handle will only set keyframes on the cregion parameters. |
Thu. November 22, 2001 | |
4.9.541 | PLEASE READ AND COMMENT ON THE FOLLOWING CHANGE! In previous builds of Houdini 5 the Transform SOP had defaults $GCX, $GCY, and $GCZ for its pivot. These defaults were set in the sop's creation script to avoid breaking custom user scripts. Now these defaults are hard-coded, so scripts may be at risk. First, in case the reason for the new defaults is not clear, let me provide an example. Suppose you have an object, say a box, located at (0, 0, 4) in space. Now you apply a transform sop with the intent of rotating that box. You change the Y rotate parameter to 90 degrees.
around the world Y-axis, ending up at a new position (4, 0, 0).
degrees around its own center, so it's position is still (0, 0, 4). It is expected that most users involved in everyday modeling will want the new more intuitive behaviour. The new defaults should not cause a problem interacively. You can still set the pivot parameter to (0, 0, 0) if you want, and even make that the permanent default. Existing scripts, however, may pose a problem. These may have been written assuming a (0, 0, 0) pivot. "opscript" commands that do not set the pivot explicitly will have to be changed to set the pivot to (0, 0, 0) if that is the behaviour the script requires. Please comment on whether this change is a significant inconvenience, and if the benefits of more intuitive modeling transformations justify such inconvenience. |
Thu. November 22, 2001 | |
4.9.541 | PLEASE READ AND COMMENT ON THE FOLLOWING CHANGE! In previous builds of Houdini 5 the Transform SOP had defaults $GCX, $GCY, and $GCZ for its pivot. These defaults were set in the sop's creation script to avoid breaking custom user scripts. Now these defaults are hard-coded, so scripts may be at risk. First, in case the reason for the new defaults is not clear, let me provide an example. Suppose you have an object, say a box, located at (0, 0, 4) in space. Now you apply a transform sop with the intent of rotating that box. You change the Y rotate parameter to 90 degrees.
around the world Y-axis, ending up at a new position (4, 0, 0).
degrees around its own center, so it's position is still (0, 0, 4). It is expected that most users involved in everyday modeling will want the new more intuitive behaviour. The new defaults should not cause a problem interacively. You can still set the pivot parameter to (0, 0, 0) if you want, and even make that the permanent default. Existing scripts, however, may pose a problem. These may have been written assuming a (0, 0, 0) pivot. "opscript" commands that do not set the pivot explicitly will have to be changed to set the pivot to (0, 0, 0) if that is the behaviour the script requires. Please comment on whether this change is a significant inconvenience, and if the benefits of more intuitive modeling transformations justify such inconvenience. |
Thu. November 22, 2001 | |
4.9.541 | PLEASE READ AND COMMENT ON THE FOLLOWING CHANGE! In previous builds of Houdini 5 the Transform SOP had defaults $GCX, $GCY, and $GCZ for its pivot. These defaults were set in the sop's creation script to avoid breaking custom user scripts. Now these defaults are hard-coded, so scripts may be at risk. First, in case the reason for the new defaults is not clear, let me provide an example. Suppose you have an object, say a box, located at (0, 0, 4) in space. Now you apply a transform sop with the intent of rotating that box. You change the Y rotate parameter to 90 degrees.
around the world Y-axis, ending up at a new position (4, 0, 0).
degrees around its own center, so it's position is still (0, 0, 4). It is expected that most users involved in everyday modeling will want the new more intuitive behaviour. The new defaults should not cause a problem interacively. You can still set the pivot parameter to (0, 0, 0) if you want, and even make that the permanent default. Existing scripts, however, may pose a problem. These may have been written assuming a (0, 0, 0) pivot. "opscript" commands that do not set the pivot explicitly will have to be changed to set the pivot to (0, 0, 0) if that is the behaviour the script requires. Please comment on whether this change is a significant inconvenience, and if the benefits of more intuitive modeling transformations justify such inconvenience. |
Thu. November 22, 2001 | |
4.9.541 | PLEASE READ AND COMMENT ON THE FOLLOWING CHANGE! In previous builds of Houdini 5 the Transform SOP had defaults $GCX, $GCY, and $GCZ for its pivot. These defaults were set in the sop's creation script to avoid breaking custom user scripts. Now these defaults are hard-coded, so scripts may be at risk. First, in case the reason for the new defaults is not clear, let me provide an example. Suppose you have an object, say a box, located at (0, 0, 4) in space. Now you apply a transform sop with the intent of rotating that box. You change the Y rotate parameter to 90 degrees.
around the world Y-axis, ending up at a new position (4, 0, 0).
degrees around its own center, so it's position is still (0, 0, 4). It is expected that most users involved in everyday modeling will want the new more intuitive behaviour. The new defaults should not cause a problem interacively. You can still set the pivot parameter to (0, 0, 0) if you want, and even make that the permanent default. Existing scripts, however, may pose a problem. These may have been written assuming a (0, 0, 0) pivot. "opscript" commands that do not set the pivot explicitly will have to be changed to set the pivot to (0, 0, 0) if that is the behaviour the script requires. Please comment on whether this change is a significant inconvenience, and if the benefits of more intuitive modeling transformations justify such inconvenience. |
Thu. November 22, 2001 | |
4.9.541 | PLEASE READ AND COMMENT ON THE FOLLOWING CHANGE! In previous builds of Houdini 5 the Transform SOP had defaults $GCX, $GCY, and $GCZ for its pivot. These defaults were set in the sop's creation script to avoid breaking custom user scripts. Now these defaults are hard-coded, so scripts may be at risk. First, in case the reason for the new defaults is not clear, let me provide an example. Suppose you have an object, say a box, located at (0, 0, 4) in space. Now you apply a transform sop with the intent of rotating that box. You change the Y rotate parameter to 90 degrees.
around the world Y-axis, ending up at a new position (4, 0, 0).
degrees around its own center, so it's position is still (0, 0, 4). It is expected that most users involved in everyday modeling will want the new more intuitive behaviour. The new defaults should not cause a problem interacively. You can still set the pivot parameter to (0, 0, 0) if you want, and even make that the permanent default. Existing scripts, however, may pose a problem. These may have been written assuming a (0, 0, 0) pivot. "opscript" commands that do not set the pivot explicitly will have to be changed to set the pivot to (0, 0, 0) if that is the behaviour the script requires. Please comment on whether this change is a significant inconvenience, and if the benefits of more intuitive modeling transformations justify such inconvenience. |
Thu. November 22, 2001 | |
4.9.540 | When deleting a group from the channel list using the pull down menu, we now correctly delete the associated group as opposed to the currently selected group which may not be the same thing. |
Wed. November 21, 2001 | |
4.9.540 | When deleting a group from the channel list using the pull down menu, we now correctly delete the associated group as opposed to the currently selected group which may not be the same thing. |
Wed. November 21, 2001 | |
4.9.540 | When deleting a group from the channel list using the pull down menu, we now correctly delete the associated group as opposed to the currently selected group which may not be the same thing. |
Wed. November 21, 2001 | |
4.9.540 | When deleting a group from the channel list using the pull down menu, we now correctly delete the associated group as opposed to the currently selected group which may not be the same thing. |
Wed. November 21, 2001 | |
4.9.540 | When deleting a group from the channel list using the pull down menu, we now correctly delete the associated group as opposed to the currently selected group which may not be the same thing. |
Wed. November 21, 2001 | |
4.9.540 | The chadd hscript command's -f and -t options now work. |
Wed. November 21, 2001 | |
4.9.540 | The chadd hscript command's -f and -t options now work. |
Wed. November 21, 2001 | |
4.9.540 | The chadd hscript command's -f and -t options now work. |
Wed. November 21, 2001 | |
4.9.540 | The chadd hscript command's -f and -t options now work. |
Wed. November 21, 2001 |