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.
I adjust a light in Redshift RenderView and the image updates almost instantly. Then I start the final render, and suddenly the same scene takes far longer. The reason is not that IPR somehow produces the same final quality much 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 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: IPR and final are two different render 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 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 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 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 my Interactive and Final settings already match closely but the final render is still slowing down because Redshift is going out of core, the bottleneck may simply be VRAM. This is where I would consider moving the scene to a GPU with more memory. iRender currently offers an RTX 5090 with 32GB GDDR7, alongside RTX 4090 configurations with 24GB VRAM per GPU. A scene that exceeds 24GB but fits within 32GB may therefore stay in GPU memory on a 5090 instead of relying as heavily on slower out-of-core memory.
One detail matters here: VRAM does not add up across multiple GPUs. An 8x RTX 4090 machine does not give one Redshift scene a 192GB VRAM pool. Each RTX 4090 still has 24GB available per card. Multiple GPUs can accelerate Redshift rendering by processing work in parallel, but they do not turn separate VRAM capacities into one larger memory pool for the scene.
For other workflows, I would also consider GarageFarm for submitted render jobs, Fox Renderfarm when batch rendering is the priority, RebusFarm for its scene submission workflow, or SheepIt as a free Blender-only option. The right choice depends on whether I need a full remote workstation or simply want to submit frames to a render farm.
If my final render is slow because the scene exceeds available VRAM, a GPU with more memory may address the bottleneck more directly than further tweaking render settings. iRender offers RTX 5090 GPUs with 32GB GDDR7 for scenes that need more than 24GB VRAM, alongside RTX 4090 24GB for less memory-intensive workloads. New accounts receive a 100% first-deposit bonus for transactions made within 24 hours of registration, and a free trial is available to test the scene first.
Explore iRender for more VRAM and faster Redshift rendering
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