Houdini Main Changelogs
 |
5.0.1 | When generating RIB for prman 10, lights will now use string handles (where the string is the name of the light). This makes the RIB more readable. This is only true if prma10 is chosen as the RIB target in the output driver. |
Sat. January 12, 2002 |
|
5.0.1 | When generating RIB for prman 10, lights will now use string handles (where the string is the name of the light). This makes the RIB more readable. This is only true if prma10 is chosen as the RIB target in the output driver. |
Sat. January 12, 2002 |
|
5.0.1 | When generating RIB for prman 10, lights will now use string handles (where the string is the name of the light). This makes the RIB more readable. This is only true if prma10 is chosen as the RIB target in the output driver. |
Sat. January 12, 2002 |
|
5.0.1 | Added support for the "facevarying" type defined in Pixar's Renderman 10. Now, all "varying" vertex attributes are output as "facevarying" automatically. This is NOT true for "vertex" attributes. |
Sat. January 12, 2002 |
|
5.0.1 | Added support for the "facevarying" type defined in Pixar's Renderman 10. Now, all "varying" vertex attributes are output as "facevarying" automatically. This is NOT true for "vertex" attributes. |
Sat. January 12, 2002 |
|
5.0.1 | Added support for the "facevarying" type defined in Pixar's Renderman 10. Now, all "varying" vertex attributes are output as "facevarying" automatically. This is NOT true for "vertex" attributes. |
Sat. January 12, 2002 |
|
5.0.1 | Added support for the "facevarying" type defined in Pixar's Renderman 10. Now, all "varying" vertex attributes are output as "facevarying" automatically. This is NOT true for "vertex" attributes. |
Sat. January 12, 2002 |
|
5.0.1 | Added support for the "facevarying" type defined in Pixar's Renderman 10. Now, all "varying" vertex attributes are output as "facevarying" automatically. This is NOT true for "vertex" attributes. |
Sat. January 12, 2002 |
 |
4.9.590 | As the title says: Bumped up the version to 5.0.0 | Fri. January 11, 2002 |
|
4.9.590 | As the title says: Bumped up the version to 5.0.0 | Fri. January 11, 2002 |
|
4.9.590 | As the title says: Bumped up the version to 5.0.0 | Fri. January 11, 2002 |
|
4.9.590 | As the title says: Bumped up the version to 5.0.0 | Fri. January 11, 2002 |
|
4.9.590 | As the title says: Bumped up the version to 5.0.0 | Fri. January 11, 2002 |
|
4.9.590 | Fixed bug which could cause user to lose data if user chose "Save & Load" or "Save & Quit" options when loading a file or quitting Houdini respectively. Previously, if the user tried to save to a file that is not writeable, then the data would be lost since Houdini would just continue to load a new file or quit. |
Fri. January 11, 2002 |
|
4.9.590 | Fixed bug which could cause user to lose data if user chose "Save & Load" or "Save & Quit" options when loading a file or quitting Houdini respectively. Previously, if the user tried to save to a file that is not writeable, then the data would be lost since Houdini would just continue to load a new file or quit. |
Fri. January 11, 2002 |
|
4.9.590 | Fixed bug which could cause user to lose data if user chose "Save & Load" or "Save & Quit" options when loading a file or quitting Houdini respectively. Previously, if the user tried to save to a file that is not writeable, then the data would be lost since Houdini would just continue to load a new file or quit. |
Fri. January 11, 2002 |
|
4.9.590 | Fixed bug which could cause user to lose data if user chose "Save & Load" or "Save & Quit" options when loading a file or quitting Houdini respectively. Previously, if the user tried to save to a file that is not writeable, then the data would be lost since Houdini would just continue to load a new file or quit. |
Fri. January 11, 2002 |
|
4.9.590 | Fixed bug which could cause user to lose data if user chose "Save & Load" or "Save & Quit" options when loading a file or quitting Houdini respectively. Previously, if the user tried to save to a file that is not writeable, then the data would be lost since Houdini would just continue to load a new file or quit. |
Fri. January 11, 2002 |
|
4.9.590 | The object viewport no longer multiplies the display option LOD level with the individual object's render LOD level for display. |
Fri. January 11, 2002 |
|
4.9.590 | The object viewport no longer multiplies the display option LOD level with the individual object's render LOD level for display. |
Fri. January 11, 2002 |
|
4.9.590 | The object viewport no longer multiplies the display option LOD level with the individual object's render LOD level for display. |
Fri. January 11, 2002 |
|
4.9.590 | The object viewport no longer multiplies the display option LOD level with the individual object's render LOD level for display. |
Fri. January 11, 2002 |
|
4.9.590 | The object viewport no longer multiplies the display option LOD level with the individual object's render LOD level for display. |
Fri. January 11, 2002 |
|
4.9.590 | MPlay's -g and -G options have been revised. By default, MPlay now groups all the command line images into a single sequence and sorts them. If -u is specified, the images are not sorted and displayed as they are passed in the command line. The -g option will attempt to group files of the same base name and extension into separate sequences (which was the default MPlay behaviour before). |
Fri. January 11, 2002 |
|
4.9.590 | MPlay's -g and -G options have been revised. By default, MPlay now groups all the command line images into a single sequence and sorts them. If -u is specified, the images are not sorted and displayed as they are passed in the command line. The -g option will attempt to group files of the same base name and extension into separate sequences (which was the default MPlay behaviour before). |
Fri. January 11, 2002 |