Table Of Contents
Overview
|
Cinema 4D Advanced System Settings |
Log and Feedback
|
Cinema 4D Log and Feedback |
During its execution, 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.
Verbosity
Controls how much detail is show in the 3d app's script/console window that pertains to Redshift rendering from the following options:
- Errors and Warnings (default) - Only show errors and warnings in the 3d app's script/console window, the most critical things for quickly being notified about problems with the scene.
- Detailed Info - Show more detailed information in the 3d app's script/console window.
- Debug - Show all messages, the most detailed information, in the 3d app's script/console window.
Diagnostic Messages
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.
Log IPR Messages
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.
Scene/Geometry Issues
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.
Abort on License Failure
When enabled, it aborts rendering when Redshift licensing fails.
Abort on Missing Resources
When enabled, it aborts rendering when the scene is missing resources like textures and other external references.
Display Behavior
Controls when the Redshift Feedback Display is automatically popped open on screen from the following options:
- Always - Always show the Feedback Display with each render.
- Errors and Warnings (default) - Only show the Feedback Display when errors and / or warnings are found.
- Errors Only - Only show the Feedback Display when errors are found.
- Never - Never automatically pop up the Feedback Display.
Show Feedback Display
A button to open the Redshift Feedback Display
Bucket Rendering
|
Cinema 4D Bucket Rendering |
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'.
Bucket Size
Controls the size of the buckets when rendering from the following options:
- 64 - Renders in 64x64 pixel square buckets.
- 128 (default) - Renders in 128x128 pixel square buckets.
- 256 - Renders in 256x256 pixel square buckets.
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.
Bucket Order
Controls the order in which the buckets are rendered from the following options:
- Spiral (default) - Rendering starts in the center of the frame and spirals out from there to the edges of the frame until the frame is complete.
- Horizontal - Bucket rendering starts at the top from left to right and then moves down left to right until the frame is complete.
- Hilbert - Buckets are rendered using a zig-zag pattern that is designed to pick the next closest bucket to the current one until the frame is complete.
Shader Baking
|
Cinema 4D Shader Baking |
Cinema 4D shaders are supported in Redshift by baking the shaders down to textures that are controlled by the parameters covered in this section.
Maxon Noise Shader
If you are looking to use a Cinema 4D noise shader please use Redshift's Maxon Noise shader which is natively supported by Redshift and does not require shader baking.
Texture Width
Specifies the resolution for the width of the baked textures.
Higher values result in higher resolution textures while lower values result in lower resolution textures.
Texture Height
Specifies the resolution for the height of the baked textures.
Higher values result in higher resolution textures while lower values result in lower resolution textures.
Texture Depth
Specifies the bit depth for the baked textures from the following options:
- 8-Bit (default) - Generally good enough for textures used for color.
- 16-Bit - Better for textures that may reveal banding with 8-Bit textures like bump and displacement maps.
- 32-Bit - Best for textures that may reveal banding issues like bump and displacement maps.
Sky Width
Specifies the resolution for the width of the baked texture used for the Cinema 4D Physical Sky.
Higher values result in higher resolution C4D sky textures while lower values result in lower resolution sky textures.
Sky Height
Specifies the resolution for the height of the baked texture used for the Cinema 4D Physical Sky.
Higher values result in higher resolution C4D sky textures while lower values result in lower resolution sky textures.
Sky Depth
Specifies the bit depth for the baked textures used for the Cinema 4D Physical Sky from the following options:
- 8-Bit
- 16-Bit
- 32-Bit (default)
Generally this should be left at the default 32-bit as it provides the highest quality and most realistic portrayal of the high dynamic ranges frequently found in pictures of the sky.
Freeze
When enabled, it stops Redshift from updating shader baking for Cinema 4D shaders.
Units
|
Cinema 4D Units |
Legacy Units
When enabled - by default, it forces Redshift to ignore scene-unit scale settings, so changes to Cinema 4D's Project Scale will have no impact on the look of renders.
When disabled, it allows Redshift to become scene-unit aware and changes to Cinema 4D's Project Scale will have a direct impact on the look of renders in combination with the Export Units option below.
Export Units
The export units options allows you to adjust the effective scale of your scene based off of the current Project Scale setting as defined in Cinema 4D's Project Settings.
Photometric Units to Meter Scale
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.
cd/m^2 Factor
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.
Legacy
|
Cinema 4D Legacy |
The legacy options covered in this section are mostly provided for the sake of backwards compatibility or in some cases unique global options that are generally no longer recommended as best practice. These legacy compatibility 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.
Lens Effect Camera
This option allows you to provide a single Redshift Camera tag and use its settings for all cameras in the scene.
This is provided as a backwards compatibility option to match the look of older scenes that made use of this feature.
Material Override
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 can also be known as a 'clay render' and is a useful feature when diagnosing lighting/shading issues.
Better Material Overrides in Cinema 4D
Cinema 4D features a better more flexible material override function that is built right into the Render Settings as an Effect as seen in the below. Just active Mode Clay and chose any color you like to use for the diffuse shading.
|
Creating a new Cinema 4D Material Override |
Diffuse Color
This controls the color of the lambert material used in the legacy Material Override feature.
Use Combined Trace Depth from Materials
When enabled, Redshift will use the Combined Trace Depth value set at the material level instead of the Combined Trace Depth set in the Globals 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.
Automatically Reduce Samples of Other Effects
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). |
Instance Optimizations
When enabled - by default, it forces Redshift to use an improved instancing algorithm that cuts down on scene traversal time.
This option should only be disabled if you suspect you have encountered a bug regarding Redshift rendering instances in C4D.
Volume Grid Emissions
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:
- Volume emission intensity could be too strong or too weak
- Volume emission result could show a stair-stepped effect
- Volume emission would look ok in-camera but it could be on the weak side as far as its GI contribution was concerned
Introduced in Redshift version 2.5.38
Cut-Offs Rules
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
Non-Inverse-Square Light Decay
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.5.55
Bump Sampling Technique
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 altogether.
This is provided as a backwards compatibility option to match the look of older scenes.
Introduced in Redshift version 2.6.10
No GI From Volume Scattering
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.
|
|
No GI From Volume Scattering: Disabled (default) | Enabled (legacy) |
Introduced in Redshift version 2.6.15
Color Management For Hair
When enabled, it forces Redshift to use an outdated color correction technique that results in inconsistent color for Cinema 4D hair.
This is only provided as a backwards compatibility option to match the look of older scenes.
Introduced in Redshift version 2.6.39
Color Management for X-Particles
When enabled, it forces Redshift to use an outdated color correction technique that results in inconsistent color for X-Particles.
This is only provided as a backwards compatibility option to match the look of older scenes.
Introduced in Redshift version 2.6.39
Non Scaling Of Point Clouds
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 versions 2.6.54 and 3.0.18
Color Management for Material Override
When enabled, it forces Redshift to use color management on the legacy Material Override function by applying an sRGB gamma correction.
Transformation Blur for C4D Cameras
When enabled, transformation motion blur is completely disabled for cameras in Cinema 4D.
When disabled - by default, cameras will render with transformation motion blur under the appropriate conditions.
Refraction Affects Alpha Channel
When enabled, it allows materials with refraction to contribute to the alpha channel value. For example, a material with refraction could have an alpha value below 1.0 depending on how refractive the material is.
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.
Introduced in Redshift version 3.0.31
Standard Material Conversion
This setting controls how Redshift interprets Cinema 4D Standard Materials.
- Native (default) - The latest and most advanced support for C4D Standard Materials.
- Architectural (legacy) - Uses the deprecated Redshift Architectural shader as the base for C4D Standard Material conversion.
- Material (legacy) - Uses an older version of C4D Standard Material conversion with the Redshift Material as the base.
Standard Sky Conversion
When enabled, it forces Redshift to use an outdated technique for converting a Cinema 4D Sky object and treating it as a Redshift Dome light.
When disabled, Redshift uses the latest technique for converting a Cinema 4D Sky object and treats it as a Redshift Environment shader.
Black-Body and Dispersion Technique
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.0.50
Experimental Options
|
Cinema 4D Experimental Options |
Bump Smoothing on Lighting Silhouettes
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.
Shadow Ray Biasing
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 |
Enable Secondary Ray Clamping on First Bounce
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.
Sampling Optimizations
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.
Debug Capture
|
Cinema 4D Debug Capture |
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.
Enable
When enabled, it produces a lot of extra information during rendering which is intended to help with diagnosing rendering issues.
Shader Integrity check (Very Slow)
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.
Memory
|
Cinema 4D Memory |
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!
Auto Memory Management
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).
Used GPU Memory (%)
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!
GPU Memory Release Timeout (sec)
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.
NVLink for Volume Grids
Controls how volume grids are handled on a system that is set up for NVLink from the following options:
- Automatic - Redshift will automatically use NVLink when available for volume grids that go out of core.
- Force Enabled - Redshift will use NVLink when available for volume grids.
- Force Disabled - Redshift will not use NVLink for volume grids, even if they go out of core.
NVLink for Geometry
Controls how geometry is handled on a system that is set up for NVLink from the following options:
- Automatic - Redshift will automatically use NVLink when available for geometry that goes out of core.
- Force Enabled - Redshift will use NVLink when available for geometry.
- Force Disabled - Redshift will not use NVLink for geometry, even if it goes out of core.
Irradiance Point Cloud Memory (MB)
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.
Irradiance Cache Memory (MB)
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.
Texture Cache Free Memory (%)
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:
- Say we are using a 2GB videocard and what's left after reserved buffers and rays is 1.7GB. The default 15% for the texture cache means that we can use up to 15% of that 1.7GB, i.e. approx 255MB.
- Alternatively, say we are using a videocard with 1GB and after reserved buffers and rays we are left with 700MB, the texture cache can be up to 105MB (15% of 700MB).
GPU Texture Cache Max (MB)
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.
CPU Texture Cache Max (MB)
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.
Ray Memory (MB)
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.