Table Of Contents
Houdini's Log and Feedback section is split between the "Abort Rendering on" settings found in the System tab...
...and the "Debug Options" tab of the Redshift Plugin Options menu which can be found in the Redshift toolbar.
|
When rendering Redshift will print out a multitude of useful messages in your 3d app's script/console window. In order to avoid clutter, Redshift's default behavior is to only print out a subset of all the messages it generates.
If you want to view all the messages in the script window, the user can set Redshift's verbosity level to "Debug". This option can be found in the System tab.
Apart from the 3d app's script/console window, Redshift stores all messages in log files.
Controls how much detail is show in the 3d app's script/console window that pertains to Redshift rendering from the following options:
When enabled, it prints even more detailed information to the Redshift log. This is useful for debugging a problematic scene and sharing the results with Redshift developers on the forums as outlined in the Bug Reporting thread.
When enabled, messages are printed to the Redshift Log file during Interactive IPR Rendering. This is enabled by default.
When disabled, nothing is printed to the Redshift Log file during interactive IPR rendering.
When enabled, it alerts the user via the log file to invalid geometry and other issues found in the scene so the issues can be fixed.
Only valid geometry is rendered.
When enabled, it aborts rendering when Redshift licensing fails.
When enabled, it aborts rendering when the scene is missing resources like textures and other external references.
Controls when the Redshift Feedback Display is automatically popped open on screen from the following options:
A button to open the Redshift Feedback Display
When Redshift renders in the Bucket rendering mode (set in the Sampling tab), it renders the image in square tiles, these tiles are also known as 'buckets' or 'blocks'.
Controls the size of the buckets when rendering from the following options:
The size of each bucket can be important to GPU performance!
Please keep in mind that, when rendering with multiple GPUs, using a large bucket size can reduce performance unless the frame is of a very high resolution. This is due to the 'last bucket effect' where the frame's last bucket has been assigned to a GPU and is currently rendering while the other GPUs have finished with their buckets and are waiting for that last bucket to be rendered. This effect, in essence, reduces parallelism and can waste several seconds of rendering time per frame. For this reason, we recommend using 128x128 buckets. Please refrain from using small 64x64 buckets as these can underutilize the GPU.
Controls the order in which the buckets are rendered from the following options:
Certain features of Redshift such as photographic exposure, physical sun/sky and IES light support require knowledge of the "units to meter" and "candela to square meter" settings. It's important to set these values correctly, otherwise lighting coming from physical light sources might appear too dim or too bright.
If you're working with centimeters (i.e. 1 world unit is 1 centimeter), the units to meter scale should be set to 100. That's because, in this case, 100 world units means 100cm, which means 1 meter. If you're working with meters, then it should be set to 1, because 1 world unit means 1 meter.
Photographic exposure, IES lights and the physical sky/sun use the cd/m^2 (candela to square meter) setting. Please make sure to attach a photographic exposure lens shader when using IES lights and physical sun/sky, otherwise your lighting will appear too bright or too dim.
The legacy options this section are mostly provided for backwards compatibility or in some cases unique global options that are generally no longer recommended as best practice. The legacy options allow you to more closely match the rendered results of older versions of Redshift while using a newer version of Redshift.
For example, you might want to take advantage of new Redshift features and enhancements but you still need to match the look of a scene that was created using the old Black-Body and Dispersion Technique. Instead of being forced to use a version of Redshift prior to version 3.0.50 you could use the latest version of Redshift but with the legacy option "Black-Body and Dispersion Technique" enabled.
When enabled, Redshift will use an outdated material override method to render every material in the scene with the same lambert material, its color is driven by the Diffuse Color parameter below (default grey).
This controls the color of the lambert material used in the legacy Material Override feature.
Better Material Overrides in Houdini
Houdini features more flexible material override functions through the use of a material_override primitive and stylesheets as covered here.
When enabled, Redshift will use the Combined Trace Depth value set per material instead of the Combined Trace Depth set in the Globals Render Settings tab.
When disabled - by default, Redshift will use the Combined Trace Depth value set in the Globals tab and ignore the Combined Trace Depth value set at the material level.
Example of Combined Trace Depth at the material level |
Enabled by default, Redshift distributes samples across all secondary ray type effects: brute-force GI, ambient occlusion, area lighting, reflection, refraction, etc.
Redshift attempts to shoot the user-defined number of secondary rays per pixel. It does that by dividing the number of secondary rays by the number of primary rays (unified sampling rays). For more information please see the Unified Sampling page.
Example scenario: Benefits of "Automatically Reduce Samples of Other Effects"
You've already tweaked your render settings to perfection and all surfaces look nice and clean. Then the director walks in and asks for longer motion blurs or a stronger depth-of-field effect. Doing either of these two and maintaining the same visual quality means having to increase your primary rays. If Redshift didn't divide the samples, increasing the primary rays (to clean DOF or motion blur noise) would make the entire frame considerably slower to render!
We do not recommend disabling this option.
When disabled, this division of secondary rays per primary rays no longer occurs resulting in more secondary rays being shot which can mean considerably longer render times when increasing the unified sampling primary ray count.
Automatically Reduce Samples of Other Effects: Enabled (default) Reflection rays (red) are divided by the number of primary rays (green). |
Automatically Reduce Samples of Other Effects: Disabled The same number of reflection rays (red) are shot for each primary ray (green). |
Introduced in Redshift version 2.5.38
When enabled, it forces Redshift to render with legacy (incorrect) volume grid emission for compatibility with older scenes.
Prior to this fix the following issues may arise:
Introduced in Redshift version 2.5
When enabled, it forces Redshift to use the old sampling Cut-Off rules used in Redshift versions prior to version 2.5.
This is provided as a backwards compatibility option to match the look of older scenes.
Introduced in Redshift version 2.5.55
When enabled - by default, it forces Redshift to employ a hack exclusively for lights that have linear or no decay ( non-physically correct decay) in order to make this kind of decay look ‘nicer’ when the surface that is being lit is very close to the light source, but it is not actually correct.
When this hack is disabled, the fall-off can get darker when the distance from the light is less than 1 unit, which is actually mathematically correct.
Introduced in Redshift version 2.6.10
When enabled, it forces Redshift to use an old bump-mapping technique that resulted in less detailed bump-mapping in the distance, particularly if mip-mapping is disabled.
This is provided as a backwards compatibility option to match the look of older scenes.
Introduced in Redshift version 2.6.15
When enabled, it forces Redshift to disable all global illumination contribution from Volume Scattering.
This is provided as a backwards compatibility option to match the look of older scenes.
In the example images below a light is shining primarily on a volume in the center of a room, when No GI from Volume Scattering is enabled this results in very little bounce lighting around the room which looks very unrealistic.
No GI From Volume Scattering: Disabled (default) | Enabled (legacy) |
Introduced in Redshift versions 2.6.54 and 3.0.18
When enabled, it forces Redshift to use an outdated and broken method of scaling for point clouds that use Redshift's native point primitive.
Prior to this fix, if you had a point cloud object and you scaled it, the points would move further apart or closer together but their actual radius wouldn’t change. I.e. the points wouldn’t become smaller or bigger!
This is only provided as a backwards compatibility option to match the look of older scenes.
Introduced in Redshift version 3.0.31
When enabled, it allows materials with refraction to contribute to the alpha channel. For example, a material with refraction could have an alpha value below 1.0 as long as it isn't refracting something else with an alpha value of 1 like another object or light.
By default, when this option is disabled, alpha channels are completely
unaffected by refraction - leaving opacity as the only material property that will affect alpha channel values.
Enabling "Refraction Affects Alpha Channel" may be a desirable workflow but please keep in mind that compositing renders on top of other elements will not be technically correct since material refractions should bend the rays.
Refraction affects alpha can be overridden per-material with the Opacity Affects Alpha Channel parameter found in the advanced section of a Redshift material.
Refraction Affects Alpha Channel: Disabled Color Channel: Alpha |
Enabled Alpha |
Enabled Beauty |
A dome light is used with a replace alpha value of 0. |
Introduced in Redshift version 3.0.50
When enabled, it forces Redshift to use an old inaccurate and physically incorrect method of rendering black-body (light temperature) and dispersion (abbe) shading that does not work correctly with OCIO rendering.
When disabled - by default, Redshift uses a new and improved rendering method for this kind of shading that features increased realism.
Black-Body and Dispersion Technique: Enabled (old) |
Disabled (new) | Enabled (old) | Disabled (new) |
Introduced in Redshift version 3.5.05
When enabled, it forces Redshift to render without sub-surface scattering global illumination.
When disabled - by default, Redshift renders with sub-surface scattering global illumination.
Sub-Surface Scattering GI: Enabled (old) SSS shader Scale: 10 |
Disabled (new) 10 |
Disabled (new) 1 |
SSS scale must be high enough that the light can pass to the other side of a object or else there will be little to no SSS GI contribution. |
Introduced in Redshift version 3.5.05
When enabled, it forces Redshift to use an outdated method of volume anisotropy for global volume fog that is less stable and breaks down at extreme values.
When disabled - by default, Redshift uses a an improved method of volume anisotropy for the global volume fog that is more stable and holds up better at extreme values.
Global Volume Anisotropy: Enabled (old) Volume Anisotropy: 0.95 |
Disabled (new) 0.95 |
Enabled (old) -0.95 |
Disabled (new) -0.95 |
Introduced in Redshift version 3.5.13
When enabled, it forces Redshift to use an outdated dispersion rendering technique that stops materials with dispersion from being visible through other materials that also have dispersion.
When disabled - by default, materials with dispersion can be seen through other materials with dispersion as you would expect.
Note: Extremely low dispersion values were used for demonstration in the example images below.
Legacy Dispersion Nested: Enabled (old) |
Disabled (new) |
Interior objects by themselves |
Introduced in Redshift version 3.5.15
When enabled, Redshift uses an old version of time management.
When disabled - by default, Redshift uses a new version of time management that enables new features like the looping functionality in a Maxon Noise shader.
Introduced in Redshift version 2025.0
Conserve Reflection Energy (CRE) is a Global Illumination feature that approximates the look of caustics by simulating very soft bounces of light. While the CRE effect looks nice without caustics, when rendering with caustics the effect is redundant and decreases the contrast provided by actual caustics.
When enabled and rendering with Photon Caustics, Conserve Reflection Energy is enabled resulting in a less accurate render by simulating fake caustics and real caustics at the same time.
When disabled and rendering with Photon Caustics, Conserve Reflection Energy is disabled resulting in a more accurate render where only real caustics are used.
GI CRE for Photon Caustics: Enabled Old behavior |
Disabled New behavior |
Enabled by default, it allows Redshift to smooth bump and normal maps on the light silhouettes of objects, where the surface normal and light direction are perpendicular to each other.
This is done to avoid faceting artifacts that can arise in those areas, especially if the object is low-poly. However, this can also produce loss of surface detail that might be necessary in some cases. For this reason, Redshift allows the user to turn off the light silhouette bump smoothing.
Enabled by default, it allows Redshift to use a ray biasing trick in order to avoid self-shadowing artifacts that are most common on low polygon meshes. For more information, please see the Shadow Ray Biasing page.
When a renderer computes shading, it uses the mesh's vertex normals. This way, if the mesh has smooth normals, the renderer can generate smooth lighting even if the mesh is of a low-tessellation. However, this can create the unfortunate situation where a vertex normal might be able to 'see' the light that the polygon cannot!
Even though shadow ray biasing can get rid of most self-shadowing issues, it can also introduce other types of artifacts in certain situations, please see here for more information.
Shadow Ray Biasing: Disabled | Enabled |
When enabled, Redshift clamps the first ray that bounces from the surface so that any secondary rays that follow are not as strong.
Clamping usually occurs after all rays are shot but in some situations where secondary rays are much stronger than primary rays enabling Secondary Ray Clamping on First Bounce can help with things like fireflies and flickering of secondary rays.
Enabled by default, it allows Redshift to further optimize sampling calculations for increased rendering speed with no loss in quality.
This should only be disabled for debugging purposes as there should be no visual differences with it enabled or disabled.
Skewed Reflection introduced in Redshift version 2025.1
Keller introduced in Redshift version 3.5.11
Controls the method used to render bump and normal maps with the following options:
Keller (Default) - Uses a method that results in fewer artifacts compared to "None," accentuates light that enters the surface at a parallel angle.
Skewed Reflection - Uses an alternative method to Keller, captures more light from all around the surface.
None - Uses the legacy method that is more prone to visual artifacts.
The difference can be subtle between Keller and Skewed Reflection but tends to become more apparent along edges and at an angle to a flat surface as seen below.
Normal Technique: Keller | Skewed Reflection | None |
If the user gets a GPU crash, they will see a message recommending that they re-render their frame using the 'debug capture' option enabled. This option allows Redshift to produce a lot of extra information during rendering which, when sent to the developers, can help them diagnose and fix issues.
When enabled, it produces a lot of extra information during rendering which is intended to help with diagnosing rendering issues.
When enabled, it checks the integrity of the shaders during rendering which is intended to help with diagnosing rendering issues.
Enabling this option will result in very slow rendering.
For additional information on this subject please see the Memory page here.
This is only for advanced users! Incorrect settings can result in poor rendering performance and/or crashes!
When enabled, it allows Redshift to analyze the scene and determine how GPU memory should be partitioned automatically between rays, geometry and textures.
When Auto Memory Management is enabled many parameters below are grayed out and uneditable.
We recommend leaving Auto Memory Management enabled unless you are an advanced user and have observed Redshift making the wrong decision (because of a bug or some other kind of limitation).
Controls how much of a GPU's memory is reserved for Redshift.
By default, Redshift reserves 90% of a GPU's free memory. This means that all other GPU apps and the OS get the remaining 10%. If you are running other GPU-heavy apps during rendering and encountering issues with them, you can reduce that figure to 80 or 70. On the other hand, if you know that no other app will use the GPU, you can increase it to 100%.
Please note that increasing the percentage beyond 90% is not typically recommended as it might introduce system instabilities and/or driver crashes!
Controls how long Redshift will hold onto your GPU's memory in seconds.
Redshift reserves a percentage of your GPU's free memory in order to operate but the process of reserving and freeing GPU memory is an expensive operation so Redshift will hold on to GPU memory while there is any rendering activity, including shaderball rendering.
By default if rendering activity stops for 10 seconds, Redshift will release this memory. It does this so that other 3d applications can function without problems.
This setting was added in version 2.5.68. Previously, there were cases where Redshift could reserve memory and hold it indefinitely.
Controls how volume grids are handled on a system that is set up for NVLink from the following options:
Controls how geometry is handled on a system that is set up for NVLink from the following options:
Specifies the maximum amount of GPU memory Irradiance Point Cloud computations are allowed to use during the actual "working" process.
The default 128MB should be able to hold several hundred thousand points. This setting should be increased if you encounter a render error during computation of the irradiance point cloud.
Specifies the maximum amount of GPU memory Irradiance Cache computations are allowed to use when during the actual "working" process.
The default 128MB should be able to hold several hundred thousand points. This setting should be increased if you encounter a render error during computation of the irradiance cache.
Specifies the percentage of the leftover GPU memory that can be used for texture caching.
Once reserved memory and rays have been subtracted from free memory, the remaining memory is split between the geometry (polygons) and the texture cache (textures). The "Texture Cache Free Memory" parameter tells the renderer the percentage of free memory that it can use for texturing.
Examples:
Specifies the maximum amount of GPU memory in MB that can be used for texture caching.
This is useful for videocards with a lot of free memory. For example, say you are using a 6GB Quadro and, after reserved buffers and rays you have 5.7GB free. 15% of that is 855MB. There are extremely few scenes that will ever need such a large texture cache! If we didn't have the "Maximum Texture Cache Size" option you would have to be constantly modifying the "Percentage" option depending on the videocard you are using.
Using these two GPU texture memory options ("Percentage" and "Maximum") allows you to specify a percentage that makes sense (and 15% most often does) while not wasting memory on videocards with lots of free mem.
Specifies the maximum amount of CPU memory (system RAM) in MB that can be used for texture caching.
System RAM used by Redshift
Before texture data is sent to the GPU it is stored in CPU memory. By default, Redshift uses 4GB for this CPU storage. If you encounter performance issues with texture-heavy scenes, please increase this setting to 8GB or higher.
Specifies how much GPU memory in MB Redshift will reserve for shooting rays.
By default, If you leave Ray Memory at zero, Redshift will use a default number of MB that depends on the shader configuration.
If your scene is very lightweight in terms of polygons, or you are using a videocard with a lot of free memory, you can specify a higher budget for the rays and potentially increase your rendering performance by helping Redshift submit fewer, larger packets of work to the GPU.