Why is your C4D Redshift IPR fast but final render painfully slow? Learn how render modes, sampling, VRAM, and out-of-core memory affect render time.
Redshift IPR vs final render is one of the most common sources of confusion in Cinema 4D: the RenderView updates almost instantly, then the final render of the same scene takes far longer. The reason is not that Redshift IPR produces final quality faster. Redshift uses different render modes for interactive feedback and final output, and they do different amounts of work.
Redshift IPR in RenderView uses Progressive rendering by default, prioritizing fast feedback while skipping or replacing several production features, including unified sampling and filtering, point-based SSS, photon mapping and caustics, irradiance cache and irradiance point cloud, and some AOVs. Final rendering uses Bucket mode by default, which supports all renderer features and uses Unified Sampling to produce clean final frames. This difference alone can make a final render much slower than the Redshift IPR preview. Final output may also involve higher resolution and additional production settings. If the scene exceeds available VRAM, supported data can go out of core, adding another potential performance penalty.
The short reason: Redshift IPR and final rendering use different modes
In Redshift, Interactive Rendering in RenderView uses Progressive rendering by default, while Final Rendering uses Bucket rendering by default. Progressive repeatedly refines the whole image, making it well suited for quick feedback while I adjust lighting, materials, or the scene. Bucket rendering divides the image into smaller regions and renders each bucket to completion, making it the recommended mode for final-quality output. The two modes also differ in which Redshift features they support, which is one reason my Redshift IPR can feel fast while the final render takes much longer.
| IPR / RenderView (Progressive) | Final / Batch (Bucket) | |
| Purpose | Fast interactive feedback while adjusting the scene | Final-quality rendering |
| How it renders | Refines the entire image progressively over multiple passes | Divides the image into buckets and completes them individually |
| Resolution | Uses the RenderView resolution, which may be smaller | Uses the configured final output resolution |
| Production features | Some features are unsupported or handled differently | Supports all renderer features |
What Progressive skips that Bucket computes
A big part of the speed difference comes from features that Progressive rendering does not use. In Progressive mode, Redshift ignores Unified Sampling and filtering, replaces point-based SSS with ray-traced SSS, does not compute photon mapping or caustics, and does not use irradiance cache or irradiance point cloud because GI is evaluated with brute force instead. Some AOVs are also unavailable in Progressive. Bucket mode supports all renderer features and uses Unified Sampling, so the final render may simply have more work to do.
| Cause | Why it can make final slower | Where to check |
| Progressive vs Bucket | Progressive favors fast feedback, while Bucket renders final-quality buckets and supports all renderer features | Render Settings > Sampling, compare Interactive Rendering and Final Rendering |
| Unified Sampling | Progressive ignores Unified Sampling. Bucket can keep shooting rays until the noise target is met, depending on Threshold and sampling settings | Sampling > Automatic Sampling / Threshold / Samples Max |
| Higher output resolution | A larger final frame contains more pixels to shade and sample than a smaller RenderView window | Output resolution |
| AOVs / passes | Some AOVs are not computed in Progressive, while final output may calculate additional buffers required for production | AOV Manager / Output |
| GI method | Progressive does not use irradiance cache, irradiance point cloud, or photon mapping. A Bucket render can use these production GI methods when configured | GI settings |
| Motion blur / DOF sampling | Progressive ignores parameters tied to explicit sample counts. In Bucket mode, DOF and motion blur can require substantial sampling to clean up noise | Camera / Sampling |
| Denoising | Denoising can add processing overhead, especially for large final frames, although OIDN and OptiX can also be used interactively | Denoising settings |
| Out-of-core memory | If the final workload exceeds available VRAM, supported data can spill to system RAM, which Maxon notes is slower than staying in VRAM | Redshift log > GPU memory statistics |
Is your final render quietly going out of core?
A smaller Redshift IPR may fit comfortably in VRAM, while a full-resolution final render with additional AOVs can require more memory. When supported data no longer fits in VRAM, Redshift can move it out of core to system RAM, allowing the render to continue but at lower performance. Some data cannot use out-of-core memory. For example, volume grid data such as VDBs must fit in VRAM and can trigger an out-of-VRAM error when memory is insufficient. To check, open the Redshift Feedback Display or render log and look at the GPU memory statistics.
To reduce out-of-core rendering, I can close other applications using VRAM, move the display to another GPU if available, reduce resolution or texture memory, or use a GPU with more VRAM. Redshift’s Used GPU Memory setting defaults to 90%, leaving the remaining memory available for the operating system and other applications.
The settings to actually compare
Open Render Settings > Redshift > Sampling and compare the Interactive and Final settings directly, because they are configured separately. Check whether Interactive Rendering uses Progressive while Final uses Bucket, then compare Automatic Sampling, Samples Max, and Threshold. A very high Samples Max or a very low Threshold can give the final render more sampling work to do. Also check the AOVs, GI method, motion blur, depth of field, and output resolution, as these may differ between the Redshift IPR preview and final output.
If I am comparing the look of IPR and final, I first make sure they are being rendered under comparable conditions. A small Bucket test render is a practical way to check the final settings before committing to the full sequence.
When the fix is more VRAM, not another setting
If your settings already match and the final render still goes out of core, VRAM may be the bottleneck. Redshift documents out-of-core texturing and geometry on its Memory page, and out-of-core data is slower than data held in VRAM. Volume data such as VDB grids has to stay in VRAM, so those scenes can fail instead of slowing down.
More GPUs do not automatically mean more memory per scene. The Blender manual, for example, says each GPU can typically only access its own memory, with the exception of NVIDIA GPUs connected with NVLink; check your own engine’s documentation before assuming memory is shared. For a card with more VRAM, see our RTX 5090 review, and for rental options see our render farm ranking, which separates automated farms from remote GPU machines.
To confirm the cause first, check the GPU memory statistics in the Redshift log or Feedback Display, then read what actually fills VRAM and what to do when a scene needs more VRAM than you have.
FAQ
Why is my Redshift final render so much slower than IPR?
Redshift IPR uses Progressive rendering by default, which prioritizes fast feedback and skips or replaces several production features. Final rendering uses Bucket rendering by default, supports all renderer features, and may render at a higher resolution with additional AOVs and production settings. If the final render exceeds available VRAM, out-of-core memory can slow it down further.
What is the difference between Progressive and Bucket rendering in Redshift?
Progressive rendering continuously refines the whole image and is designed for fast interactive feedback. It does not use Unified Sampling and filtering and skips or replaces features such as irradiance cache, photon mapping, caustics, and some AOVs. Bucket rendering divides the image into regions, supports all renderer features, and is recommended by Redshift for final rendering.
How do I know if my Redshift render is going out of core?
Check the Redshift Feedback Display or render log and look at the GPU memory statistics. If the required memory exceeds the available GPU memory for supported data, Redshift can use system RAM through out-of-core rendering, which is slower than keeping the data in VRAM. Some data, including volume grids such as VDBs, cannot go out of core and may instead cause an out-of-VRAM error.
Read more: How to Cut Your Render Farm Bill in Half Without Losing Quality
Image source: Maxon
COMMENTS