Houdini Main Changelogs
4.9.437 | The Color POP now uses the alpha cop network to build the alpha cop menu as opposed to the color cop network. |
Fri. August 3, 2001 | |
4.9.437 | The Color POP now uses the alpha cop network to build the alpha cop menu as opposed to the color cop network. |
Fri. August 3, 2001 | |
4.9.437 | The Color POP now uses the alpha cop network to build the alpha cop menu as opposed to the color cop network. |
Fri. August 3, 2001 | |
4.9.437 | The Color POP now uses the alpha cop network to build the alpha cop menu as opposed to the color cop network. |
Fri. August 3, 2001 | |
4.9.437 | Sweep now allows cross-sections to inherit alpha attribute from spine. |
Fri. August 3, 2001 | |
4.9.437 | Sweep now allows cross-sections to inherit alpha attribute from spine. |
Fri. August 3, 2001 | |
4.9.437 | Sweep now allows cross-sections to inherit alpha attribute from spine. |
Fri. August 3, 2001 | |
4.9.437 | Sweep now allows cross-sections to inherit alpha attribute from spine. |
Fri. August 3, 2001 | |
4.9.437 | Sweep now allows cross-sections to inherit alpha attribute from spine. |
Fri. August 3, 2001 | |
4.9.436 | When generating .pic.gz files, if the Houdini format occurs in the dso_fb/index file before the PRISMS format, then Houdini .pic.gz files will be created properly (previously, if PRISMS existed at all, then PRISMS .pic.gz files were created). |
Thu. August 2, 2001 | |
4.9.436 | When generating .pic.gz files, if the Houdini format occurs in the dso_fb/index file before the PRISMS format, then Houdini .pic.gz files will be created properly (previously, if PRISMS existed at all, then PRISMS .pic.gz files were created). |
Thu. August 2, 2001 | |
4.9.436 | When generating .pic.gz files, if the Houdini format occurs in the dso_fb/index file before the PRISMS format, then Houdini .pic.gz files will be created properly (previously, if PRISMS existed at all, then PRISMS .pic.gz files were created). |
Thu. August 2, 2001 | |
4.9.436 | When generating .pic.gz files, if the Houdini format occurs in the dso_fb/index file before the PRISMS format, then Houdini .pic.gz files will be created properly (previously, if PRISMS existed at all, then PRISMS .pic.gz files were created). |
Thu. August 2, 2001 | |
4.9.436 | When generating .pic.gz files, if the Houdini format occurs in the dso_fb/index file before the PRISMS format, then Houdini .pic.gz files will be created properly (previously, if PRISMS existed at all, then PRISMS .pic.gz files were created). |
Thu. August 2, 2001 | |
4.9.436 | When including <math.h> in VEX code, a define was created for "E". This conflicted with the global variable "E" in the CHOP context. The work around was to have the following code in the CHOP definition: #include <math.h> #undef E However, the defines in math.h have been changes so that all mathematical constants are prefixed with M_ (i.e. M_PI instead of PI). To minimize the changes required to existing code, backward compatibility defines are created (unless the environment variable VEX_STRICT_COMPILE or the define VEX_STRICT_COMPILE exists) for all constants (excepting "E"). All standard shaders have been modified to use the new naming conventions for mathematical constants. |
Thu. August 2, 2001 | |
4.9.436 | When including <math.h> in VEX code, a define was created for "E". This conflicted with the global variable "E" in the CHOP context. The work around was to have the following code in the CHOP definition: #include <math.h> #undef E However, the defines in math.h have been changes so that all mathematical constants are prefixed with M_ (i.e. M_PI instead of PI). To minimize the changes required to existing code, backward compatibility defines are created (unless the environment variable VEX_STRICT_COMPILE or the define VEX_STRICT_COMPILE exists) for all constants (excepting "E"). All standard shaders have been modified to use the new naming conventions for mathematical constants. |
Thu. August 2, 2001 | |
4.9.436 | When including <math.h> in VEX code, a define was created for "E". This conflicted with the global variable "E" in the CHOP context. The work around was to have the following code in the CHOP definition: #include <math.h> #undef E However, the defines in math.h have been changes so that all mathematical constants are prefixed with M_ (i.e. M_PI instead of PI). To minimize the changes required to existing code, backward compatibility defines are created (unless the environment variable VEX_STRICT_COMPILE or the define VEX_STRICT_COMPILE exists) for all constants (excepting "E"). All standard shaders have been modified to use the new naming conventions for mathematical constants. |
Thu. August 2, 2001 | |
4.9.436 | When including <math.h> in VEX code, a define was created for "E". This conflicted with the global variable "E" in the CHOP context. The work around was to have the following code in the CHOP definition: #include <math.h> #undef E However, the defines in math.h have been changes so that all mathematical constants are prefixed with M_ (i.e. M_PI instead of PI). To minimize the changes required to existing code, backward compatibility defines are created (unless the environment variable VEX_STRICT_COMPILE or the define VEX_STRICT_COMPILE exists) for all constants (excepting "E"). All standard shaders have been modified to use the new naming conventions for mathematical constants. |
Thu. August 2, 2001 | |
4.9.436 | When including <math.h> in VEX code, a define was created for "E". This conflicted with the global variable "E" in the CHOP context. The work around was to have the following code in the CHOP definition: #include <math.h> #undef E However, the defines in math.h have been changes so that all mathematical constants are prefixed with M_ (i.e. M_PI instead of PI). To minimize the changes required to existing code, backward compatibility defines are created (unless the environment variable VEX_STRICT_COMPILE or the define VEX_STRICT_COMPILE exists) for all constants (excepting "E"). All standard shaders have been modified to use the new naming conventions for mathematical constants. |
Thu. August 2, 2001 | |
4.9.436 | It is now possible to specify object groups that are contained in subnets as part of your light masks, shadow masks, etc. To specify the "lights" group contained in subnet1, use "@subnet1/lights". Note that this value is the same whether you are setting the light mask for "/obj/geo1", or "/obj/subnet1/geo1". Similarly, if you specify a light mask of "light1" for "/obj/subnet1/geo1", this really means "/obj/light1", not "/obj/subnet1/light1". To specify "/obj/subnet1/light1" in the light mask, use "subnet1/light1". |
Thu. August 2, 2001 | |
4.9.436 | It is now possible to specify object groups that are contained in subnets as part of your light masks, shadow masks, etc. To specify the "lights" group contained in subnet1, use "@subnet1/lights". Note that this value is the same whether you are setting the light mask for "/obj/geo1", or "/obj/subnet1/geo1". Similarly, if you specify a light mask of "light1" for "/obj/subnet1/geo1", this really means "/obj/light1", not "/obj/subnet1/light1". To specify "/obj/subnet1/light1" in the light mask, use "subnet1/light1". |
Thu. August 2, 2001 | |
4.9.436 | It is now possible to specify object groups that are contained in subnets as part of your light masks, shadow masks, etc. To specify the "lights" group contained in subnet1, use "@subnet1/lights". Note that this value is the same whether you are setting the light mask for "/obj/geo1", or "/obj/subnet1/geo1". Similarly, if you specify a light mask of "light1" for "/obj/subnet1/geo1", this really means "/obj/light1", not "/obj/subnet1/light1". To specify "/obj/subnet1/light1" in the light mask, use "subnet1/light1". |
Thu. August 2, 2001 | |
4.9.436 | It is now possible to specify object groups that are contained in subnets as part of your light masks, shadow masks, etc. To specify the "lights" group contained in subnet1, use "@subnet1/lights". Note that this value is the same whether you are setting the light mask for "/obj/geo1", or "/obj/subnet1/geo1". Similarly, if you specify a light mask of "light1" for "/obj/subnet1/geo1", this really means "/obj/light1", not "/obj/subnet1/light1". To specify "/obj/subnet1/light1" in the light mask, use "subnet1/light1". |
Thu. August 2, 2001 | |
4.9.436 | It is now possible to specify object groups that are contained in subnets as part of your light masks, shadow masks, etc. To specify the "lights" group contained in subnet1, use "@subnet1/lights". Note that this value is the same whether you are setting the light mask for "/obj/geo1", or "/obj/subnet1/geo1". Similarly, if you specify a light mask of "light1" for "/obj/subnet1/geo1", this really means "/obj/light1", not "/obj/subnet1/light1". To specify "/obj/subnet1/light1" in the light mask, use "subnet1/light1". |
Thu. August 2, 2001 | |
4.9.436 | PolySplit state will now take the input geometry in consideration when it computes the snap tolerance. Also, a slew of bugs related to synchronizing the network with the state were fixed. |
Thu. August 2, 2001 |