The Color POP now uses the alpha cop network to build the alpha cop menu as opposed to the color cop network.

The Color POP now uses the alpha cop network to build the alpha cop menu as opposed to the color cop network.

The Color POP now uses the alpha cop network to build the alpha cop menu as opposed to the color cop network.

Sweep now allows cross-sections to inherit alpha attribute from spine.

Sweep now allows cross-sections to inherit alpha attribute from spine.

Sweep now allows cross-sections to inherit alpha attribute from spine.

Sweep now allows cross-sections to inherit alpha attribute from spine.

Sweep now allows cross-sections to inherit alpha attribute from spine.

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).

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).

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).

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).

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).

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.

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.

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.

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.

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.

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".

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".

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".

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".

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".

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.

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.