A few additions to IGES support:

• Support for Name Properties (IGES Type 406 From 15) as groups in Houdini.
• Support for Level Function Properties (IGES Type 406 Form 3) as groups inHoudini.
• Support for the level entry. All entities on the same level now getgrouped in the same group.

A few additions to IGES support:

• Support for Name Properties (IGES Type 406 From 15) as groups in Houdini.
• Support for Level Function Properties (IGES Type 406 Form 3) as groups inHoudini.
• Support for the level entry. All entities on the same level now getgrouped in the same group.

A few additions to IGES support:

• Support for Name Properties (IGES Type 406 From 15) as groups in Houdini.
• Support for Level Function Properties (IGES Type 406 Form 3) as groups inHoudini.
• Support for the level entry. All entities on the same level now getgrouped in the same group.

Added new object-level Dynamic Parent operation. The pop up help from the operation is quoted here:

The Dynamic Parent operation allows you to do dynamically parent objects over time. With it, you can easily pass child objects from one parent to another (either within a single frame or over a range of frames). This is done with the aid of a Blend object and several Null objects.

When you start this operation, you will be prompted to select the child object which is to be passed between the parents. When you are done selecting the child object, its wireframe will be drawn with a dotted line for the duration of the operation.

Note: If the selected child object has no existing parents, then a Null parent object (named 'start_null') will be created, and the child's transformations will be transferred. This will modify any animation that the child object may already have, so we recommend that the child object only be animated after an start_null parent has been created for it.

Once the child object has been selected, the Operation controls toolbar (above the Viewport) can be used to Add, Replace, or Snap transitions.

When you click the Add Transition button, the operation controls will change to allow you to set the frame offset for the current transition. You are also prompted to select the new parent to transition to.

If the frame offset is set to 0, then the transition will occur instaneously (i.e. at the current frame). If set to something larger than 0, then the transition will occur over the specified number of frames starting from the current frame. The transition is accomplished by adding a special Null object named 'transition_null' to carry the child object from the current frame to the destination frame (i.e. current frame + frame offset) of the new parent.

Keys will be created in the Blend object's Sequence parameter, and in the transition object's Transform parameters to accomplish the transition. These transition objects can then be animated to precisely control the path of the child during the transition.

For transitions within a single frame (frame offset 0), special Null objects named 'offset_null' are created to ensure there will be no popping while transitioning between parents. Also, special channel groups named 'Transition' are created to help manage the channels used.

The Replace Transition button will allow you to change an existing transition (at the current frame) to the new parent. It modifies existing keys at the starting and ending frames of the current transition to do this.

The Snap Transitions button will go through all the keys of the Blend object's Sequence parameter and snap the keys of the transition objects to match the transitioning parents. This is often handy to fix the transitions after the transitioning parents have had their animation changed.

The Visibility button brings up a menu to control the display of the transition objects associated with the currently attached child object.

Added new object-level Dynamic Parent operation. The pop up help from the operation is quoted here:

The Dynamic Parent operation allows you to do dynamically parent objects over time. With it, you can easily pass child objects from one parent to another (either within a single frame or over a range of frames). This is done with the aid of a Blend object and several Null objects.

When you start this operation, you will be prompted to select the child object which is to be passed between the parents. When you are done selecting the child object, its wireframe will be drawn with a dotted line for the duration of the operation.

Note: If the selected child object has no existing parents, then a Null parent object (named 'start_null') will be created, and the child's transformations will be transferred. This will modify any animation that the child object may already have, so we recommend that the child object only be animated after an start_null parent has been created for it.

Once the child object has been selected, the Operation controls toolbar (above the Viewport) can be used to Add, Replace, or Snap transitions.

When you click the Add Transition button, the operation controls will change to allow you to set the frame offset for the current transition. You are also prompted to select the new parent to transition to.

If the frame offset is set to 0, then the transition will occur instaneously (i.e. at the current frame). If set to something larger than 0, then the transition will occur over the specified number of frames starting from the current frame. The transition is accomplished by adding a special Null object named 'transition_null' to carry the child object from the current frame to the destination frame (i.e. current frame + frame offset) of the new parent.

Keys will be created in the Blend object's Sequence parameter, and in the transition object's Transform parameters to accomplish the transition. These transition objects can then be animated to precisely control the path of the child during the transition.

For transitions within a single frame (frame offset 0), special Null objects named 'offset_null' are created to ensure there will be no popping while transitioning between parents. Also, special channel groups named 'Transition' are created to help manage the channels used.

The Replace Transition button will allow you to change an existing transition (at the current frame) to the new parent. It modifies existing keys at the starting and ending frames of the current transition to do this.

The Snap Transitions button will go through all the keys of the Blend object's Sequence parameter and snap the keys of the transition objects to match the transitioning parents. This is often handy to fix the transitions after the transitioning parents have had their animation changed.

The Visibility button brings up a menu to control the display of the transition objects associated with the currently attached child object.

Added new object-level Dynamic Parent operation. The pop up help from the operation is quoted here:

The Dynamic Parent operation allows you to do dynamically parent objects over time. With it, you can easily pass child objects from one parent to another (either within a single frame or over a range of frames). This is done with the aid of a Blend object and several Null objects.

When you start this operation, you will be prompted to select the child object which is to be passed between the parents. When you are done selecting the child object, its wireframe will be drawn with a dotted line for the duration of the operation.

Note: If the selected child object has no existing parents, then a Null parent object (named 'start_null') will be created, and the child's transformations will be transferred. This will modify any animation that the child object may already have, so we recommend that the child object only be animated after an start_null parent has been created for it.

Once the child object has been selected, the Operation controls toolbar (above the Viewport) can be used to Add, Replace, or Snap transitions.

When you click the Add Transition button, the operation controls will change to allow you to set the frame offset for the current transition. You are also prompted to select the new parent to transition to.

If the frame offset is set to 0, then the transition will occur instaneously (i.e. at the current frame). If set to something larger than 0, then the transition will occur over the specified number of frames starting from the current frame. The transition is accomplished by adding a special Null object named 'transition_null' to carry the child object from the current frame to the destination frame (i.e. current frame + frame offset) of the new parent.

Keys will be created in the Blend object's Sequence parameter, and in the transition object's Transform parameters to accomplish the transition. These transition objects can then be animated to precisely control the path of the child during the transition.

For transitions within a single frame (frame offset 0), special Null objects named 'offset_null' are created to ensure there will be no popping while transitioning between parents. Also, special channel groups named 'Transition' are created to help manage the channels used.

The Replace Transition button will allow you to change an existing transition (at the current frame) to the new parent. It modifies existing keys at the starting and ending frames of the current transition to do this.

The Snap Transitions button will go through all the keys of the Blend object's Sequence parameter and snap the keys of the transition objects to match the transitioning parents. This is often handy to fix the transitions after the transitioning parents have had their animation changed.

The Visibility button brings up a menu to control the display of the transition objects associated with the currently attached child object.

Added new object-level Dynamic Parent operation. The pop up help from the operation is quoted here:

The Dynamic Parent operation allows you to do dynamically parent objects over time. With it, you can easily pass child objects from one parent to another (either within a single frame or over a range of frames). This is done with the aid of a Blend object and several Null objects.

When you start this operation, you will be prompted to select the child object which is to be passed between the parents. When you are done selecting the child object, its wireframe will be drawn with a dotted line for the duration of the operation.

Note: If the selected child object has no existing parents, then a Null parent object (named 'start_null') will be created, and the child's transformations will be transferred. This will modify any animation that the child object may already have, so we recommend that the child object only be animated after an start_null parent has been created for it.

Once the child object has been selected, the Operation controls toolbar (above the Viewport) can be used to Add, Replace, or Snap transitions.

When you click the Add Transition button, the operation controls will change to allow you to set the frame offset for the current transition. You are also prompted to select the new parent to transition to.

If the frame offset is set to 0, then the transition will occur instaneously (i.e. at the current frame). If set to something larger than 0, then the transition will occur over the specified number of frames starting from the current frame. The transition is accomplished by adding a special Null object named 'transition_null' to carry the child object from the current frame to the destination frame (i.e. current frame + frame offset) of the new parent.

Keys will be created in the Blend object's Sequence parameter, and in the transition object's Transform parameters to accomplish the transition. These transition objects can then be animated to precisely control the path of the child during the transition.

For transitions within a single frame (frame offset 0), special Null objects named 'offset_null' are created to ensure there will be no popping while transitioning between parents. Also, special channel groups named 'Transition' are created to help manage the channels used.

The Replace Transition button will allow you to change an existing transition (at the current frame) to the new parent. It modifies existing keys at the starting and ending frames of the current transition to do this.

The Snap Transitions button will go through all the keys of the Blend object's Sequence parameter and snap the keys of the transition objects to match the transitioning parents. This is often handy to fix the transitions after the transitioning parents have had their animation changed.

The Visibility button brings up a menu to control the display of the transition objects associated with the currently attached child object.

Added new object-level Dynamic Parent operation. The pop up help from the operation is quoted here:

The Dynamic Parent operation allows you to do dynamically parent objects over time. With it, you can easily pass child objects from one parent to another (either within a single frame or over a range of frames). This is done with the aid of a Blend object and several Null objects.

When you start this operation, you will be prompted to select the child object which is to be passed between the parents. When you are done selecting the child object, its wireframe will be drawn with a dotted line for the duration of the operation.

Note: If the selected child object has no existing parents, then a Null parent object (named 'start_null') will be created, and the child's transformations will be transferred. This will modify any animation that the child object may already have, so we recommend that the child object only be animated after an start_null parent has been created for it.

Once the child object has been selected, the Operation controls toolbar (above the Viewport) can be used to Add, Replace, or Snap transitions.

When you click the Add Transition button, the operation controls will change to allow you to set the frame offset for the current transition. You are also prompted to select the new parent to transition to.

If the frame offset is set to 0, then the transition will occur instaneously (i.e. at the current frame). If set to something larger than 0, then the transition will occur over the specified number of frames starting from the current frame. The transition is accomplished by adding a special Null object named 'transition_null' to carry the child object from the current frame to the destination frame (i.e. current frame + frame offset) of the new parent.

Keys will be created in the Blend object's Sequence parameter, and in the transition object's Transform parameters to accomplish the transition. These transition objects can then be animated to precisely control the path of the child during the transition.

For transitions within a single frame (frame offset 0), special Null objects named 'offset_null' are created to ensure there will be no popping while transitioning between parents. Also, special channel groups named 'Transition' are created to help manage the channels used.

The Replace Transition button will allow you to change an existing transition (at the current frame) to the new parent. It modifies existing keys at the starting and ending frames of the current transition to do this.

The Snap Transitions button will go through all the keys of the Blend object's Sequence parameter and snap the keys of the transition objects to match the transitioning parents. This is often handy to fix the transitions after the transitioning parents have had their animation changed.

The Visibility button brings up a menu to control the display of the transition objects associated with the currently attached child object.

The image chop is back and now supports COPS v2.

The image chop is back and now supports COPS v2.

The image chop is back and now supports COPS v2.

The image chop is back and now supports COPS v2.

The image chop is back and now supports COPS v2.

When binding SHOPs to geometry, SHOP references may either be direct (i.e. the shader is baked into the geometry) or indirect (i.e. the shader is referenced and resolved at IFD generation time).

The advantages of baking the shader into the IFD in the past were that the IFD was stand-alone (i.e. the geometry could be saved to disk and referenced by the renderer). However, baked shaders had many disadvantages. Each time a shader parameter changed, this caused the geometry to re-cook (which is a potentially expensive operation).

The advantages of indirect references were that since the shader was built only at render time, the geometry didn't have to re-cook every time a shader parameter changed. However, because indirect references required a SHOP to evaluate the shader string, the geometry typically had to be generated inline in IFDs, computing the shader strings when the IFD was generated. This prohibitted geometry files with indirect references from being used as archive files (read at render time).

However, there are now new options in the mantra output driver to deal with SHOP referencing:

• Harden all SHOP references. This option will force the previousbehaviour on IFD generation. All indirect references to SHOPswill have their shader strings baked into the geometry beforethe geometry is sent to the renderer.
• Indirect geometry SHOP references. With this option (thedefault), SHOPs referenced by Shader SOPs with indirectreferences will be output to mantra using the new "ray_shop"command. Indirect references will be resolved by mantra atrender time (leaving the indirect references intact).
• Declare all SHOPs. This option will force all SHOPs to bedeclared regardless of whether they are referenced bygeometry. This option is useful if disk archives are used formantra and the geometry isn't loaded into Houdini at all.

When binding SHOPs to geometry, SHOP references may either be direct (i.e. the shader is baked into the geometry) or indirect (i.e. the shader is referenced and resolved at IFD generation time).

The advantages of baking the shader into the IFD in the past were that the IFD was stand-alone (i.e. the geometry could be saved to disk and referenced by the renderer). However, baked shaders had many disadvantages. Each time a shader parameter changed, this caused the geometry to re-cook (which is a potentially expensive operation).

The advantages of indirect references were that since the shader was built only at render time, the geometry didn't have to re-cook every time a shader parameter changed. However, because indirect references required a SHOP to evaluate the shader string, the geometry typically had to be generated inline in IFDs, computing the shader strings when the IFD was generated. This prohibitted geometry files with indirect references from being used as archive files (read at render time).

However, there are now new options in the mantra output driver to deal with SHOP referencing:

• Harden all SHOP references. This option will force the previousbehaviour on IFD generation. All indirect references to SHOPswill have their shader strings baked into the geometry beforethe geometry is sent to the renderer.
• Indirect geometry SHOP references. With this option (thedefault), SHOPs referenced by Shader SOPs with indirectreferences will be output to mantra using the new "ray_shop"command. Indirect references will be resolved by mantra atrender time (leaving the indirect references intact).
• Declare all SHOPs. This option will force all SHOPs to bedeclared regardless of whether they are referenced bygeometry. This option is useful if disk archives are used formantra and the geometry isn't loaded into Houdini at all.

When binding SHOPs to geometry, SHOP references may either be direct (i.e. the shader is baked into the geometry) or indirect (i.e. the shader is referenced and resolved at IFD generation time).

The advantages of baking the shader into the IFD in the past were that the IFD was stand-alone (i.e. the geometry could be saved to disk and referenced by the renderer). However, baked shaders had many disadvantages. Each time a shader parameter changed, this caused the geometry to re-cook (which is a potentially expensive operation).

The advantages of indirect references were that since the shader was built only at render time, the geometry didn't have to re-cook every time a shader parameter changed. However, because indirect references required a SHOP to evaluate the shader string, the geometry typically had to be generated inline in IFDs, computing the shader strings when the IFD was generated. This prohibitted geometry files with indirect references from being used as archive files (read at render time).

However, there are now new options in the mantra output driver to deal with SHOP referencing:

• Harden all SHOP references. This option will force the previousbehaviour on IFD generation. All indirect references to SHOPswill have their shader strings baked into the geometry beforethe geometry is sent to the renderer.
• Indirect geometry SHOP references. With this option (thedefault), SHOPs referenced by Shader SOPs with indirectreferences will be output to mantra using the new "ray_shop"command. Indirect references will be resolved by mantra atrender time (leaving the indirect references intact).
• Declare all SHOPs. This option will force all SHOPs to bedeclared regardless of whether they are referenced bygeometry. This option is useful if disk archives are used formantra and the geometry isn't loaded into Houdini at all.

When binding SHOPs to geometry, SHOP references may either be direct (i.e. the shader is baked into the geometry) or indirect (i.e. the shader is referenced and resolved at IFD generation time).

The advantages of baking the shader into the IFD in the past were that the IFD was stand-alone (i.e. the geometry could be saved to disk and referenced by the renderer). However, baked shaders had many disadvantages. Each time a shader parameter changed, this caused the geometry to re-cook (which is a potentially expensive operation).

The advantages of indirect references were that since the shader was built only at render time, the geometry didn't have to re-cook every time a shader parameter changed. However, because indirect references required a SHOP to evaluate the shader string, the geometry typically had to be generated inline in IFDs, computing the shader strings when the IFD was generated. This prohibitted geometry files with indirect references from being used as archive files (read at render time).

However, there are now new options in the mantra output driver to deal with SHOP referencing:

• Harden all SHOP references. This option will force the previousbehaviour on IFD generation. All indirect references to SHOPswill have their shader strings baked into the geometry beforethe geometry is sent to the renderer.
• Indirect geometry SHOP references. With this option (thedefault), SHOPs referenced by Shader SOPs with indirectreferences will be output to mantra using the new "ray_shop"command. Indirect references will be resolved by mantra atrender time (leaving the indirect references intact).
• Declare all SHOPs. This option will force all SHOPs to bedeclared regardless of whether they are referenced bygeometry. This option is useful if disk archives are used formantra and the geometry isn't loaded into Houdini at all.

When binding SHOPs to geometry, SHOP references may either be direct (i.e. the shader is baked into the geometry) or indirect (i.e. the shader is referenced and resolved at IFD generation time).

The advantages of baking the shader into the IFD in the past were that the IFD was stand-alone (i.e. the geometry could be saved to disk and referenced by the renderer). However, baked shaders had many disadvantages. Each time a shader parameter changed, this caused the geometry to re-cook (which is a potentially expensive operation).

The advantages of indirect references were that since the shader was built only at render time, the geometry didn't have to re-cook every time a shader parameter changed. However, because indirect references required a SHOP to evaluate the shader string, the geometry typically had to be generated inline in IFDs, computing the shader strings when the IFD was generated. This prohibitted geometry files with indirect references from being used as archive files (read at render time).

However, there are now new options in the mantra output driver to deal with SHOP referencing:

• Harden all SHOP references. This option will force the previousbehaviour on IFD generation. All indirect references to SHOPswill have their shader strings baked into the geometry beforethe geometry is sent to the renderer.
• Indirect geometry SHOP references. With this option (thedefault), SHOPs referenced by Shader SOPs with indirectreferences will be output to mantra using the new "ray_shop"command. Indirect references will be resolved by mantra atrender time (leaving the indirect references intact).
• Declare all SHOPs. This option will force all SHOPs to bedeclared regardless of whether they are referenced bygeometry. This option is useful if disk archives are used formantra and the geometry isn't loaded into Houdini at all.