Redshift Out-of-Core Memory in Cinema 4D: Texture Cache, Geometry and VRAM Limits
Redshift can render scenes larger than GPU memory by keeping geometry and textures out-of-core. The main points from Maxon's documentation:
- How memory is split: After reserved memory and rays, the rest is shared between geometry and the texture cache (15% by default).
- Out-of-core has a cost: Maxon notes excessive out-of-core access can slow renders considerably; plenty of VRAM is preferable for high-poly scenes.
- Not everything goes out-of-core: Volume grids such as OpenVDB cannot be stored out-of-core, per Maxon support.
- Textures: Redshift converts textures to its own tiled, mipmapped format and streams only the parts it needs; the Texture Processor pre-converts them.
- VRAM per GPU: VRAM is not combined across GPUs. iRender RTX 5090 servers with 32 GB per GPU keep more of a heavy scene in VRAM than 24 GB cards.
When a Redshift scene outgrows GPU memory, it usually keeps rendering, just slower, or it stops with a memory error. Knowing how Redshift splits VRAM and what can move out-of-core tells you which one you will get and what to change. This guide follows Maxon’s Redshift Memory documentation and support articles.
Checked against the Cinema 4D and Redshift documentation, November 2026.
Symptoms this guide fixes: renders that slow down sharply on heavy shots, GPU memory warnings in the log, or frames that fail when volumes or very large textures are added.
1. How does Redshift split GPU memory?
Redshift reserves memory for its modules, allocates ray memory, then splits what remains between geometry and the texture cache (Maxon: Memory). The figure shows the layout and the path out-of-core data takes.
Inside each GPU, geometry usually takes the largest share, while the texture cache is small and recycled as textures stream in. Data that does not fit moves to system RAM and travels over PCIe when needed, which is slower than VRAM. Volume grids such as OpenVDB have to stay in VRAM.
Redshift memory settings that matter
From Maxon's Redshift Memory documentation (advanced settings; wrong values can hurt performance).
| Setting | What it does | When to change it |
|---|---|---|
| Automatic Memory Management | Redshift analyzes the scene and splits GPU memory between rays, geometry and textures. | Leave on for most scenes |
| Percentage of free memory for texture cache | Share of remaining memory for textures; 15% by default. Capped by Maximum GPU Texture Cache Size. | Rarely; Maxon notes very few scenes need a huge texture cache |
| Maximum CPU Texture Cache Size | Texture data is held in CPU memory before upload; 4 GB by default. | Texture-heavy scenes: Maxon suggests 8 GB or higher |
| Ray reserved memory | Memory set aside for rays. | Only on the specific errors the docs describe |
| Texture Cache Max GB (Preferences) | Limits the disk folder of converted textures and compiled shaders; oldest files are removed when full. | When the cache drive fills up |
A note on sources about VRAM: Maxon’s support article states that Redshift does not combine the VRAM when using multiple GPUs. Maxon’s 3D rendering product page also lists “multi-GPU memory pooling” and says Redshift shares out-of-core memory across multiple cards. This article follows the support article: plan for every GPU holding the scene in its own VRAM. Check Maxon’s latest documentation for your Redshift version.
2. What does out-of-core cost, and what cannot go out-of-core?
Maxon notes that out-of-core lets even small GPUs render very high-poly scenes, but excessive out-of-core data access can introduce considerable performance penalties, so plenty of VRAM is preferable (Maxon support). Volume grids such as OpenVDB cannot be stored out-of-core. And VRAM is not combined across GPUs (Maxon support), so adding GPUs adds speed, not scene capacity.
3. How do textures and .rstexbin files fit in?
Redshift converts textures into its own renderable format, with mip maps computed using the texture’s color space, and uploads only the parts it needs (Maxon: Texture Processor). Conversion happens automatically at render time, or ahead of time with the Texture Processor, which writes the converted file next to the source with the same name.
- Pre-convert large texture sets on network storage, so each render machine does not convert them again.
- Keep file names unique regardless of extension: wall.jpg and wall.exr would produce the same converted file.
- Check the log: it lists the Texture Processor options Redshift used for each texture, such as
-cs "sRGB".
Converted textures are not shared across GPUs' memory. Converting saves time and streaming bandwidth; it does not let a scene exceed what each GPU can hold for data that must stay in VRAM.
4. How to fix out-of-core slowdowns (step by step)
Settings checklist (copy or follow line by line):
1. Measure Redshift Feedback Display ... Geometry, Texture [cache size], PCIe uploaded 2. Geometry ................... lower subdivision/displacement off-camera; proxies, instances 3. Textures Resolution ................. match screen size Pre-convert ................ redshiftTextureProcessor.exe-cs "sRGB" (color maps) redshiftTextureProcessor.exe -cs "Raw" (data maps) Maximum CPU Texture Cache .. 4 GB default → 8 GB+ for texture-heavy scenes 4. Volumes (OpenVDB) .......... must fit in VRAM: lower grid resolution or split passes 5. Still too big .............. GPUs with more VRAM per card (adding cards adds speed, not memory)
Step 1: Measure
Render a heavy frame and read the Feedback Display: geometry, texture cache and PCIe upload figures.
Step 2: Reduce geometry
Lower subdivision and displacement where the camera cannot see the detail, and use proxies or instances for repeated objects.
Step 3: Tame textures
Use texture resolutions that match screen size, pre-convert textures, and for texture-heavy scenes raise the CPU texture cache as Maxon suggests.
Step 4: Watch volumes
Volumes must fit in VRAM; reduce grid resolution or split elements into separate passes.
Step 5: Use more VRAM per GPU
If the scene still does not fit, render on GPUs with more memory per card, since adding cards does not add capacity.
Quick check: if the PCIe-uploaded figure keeps climbing far above the texture cache size on every frame, textures are streaming heavily: reduce texture resolution before buying more GPUs.
5. Where should you render memory-heavy scenes: SaaS or IaaS farm?
A SaaS render farm renders the scene as uploaded on its own hardware, which suits scenes already known to fit the farm’s GPUs. An IaaS render farm such as iRender gives you the full Cinema 4D session on the render machine, so you can read the Feedback Display, adjust memory and textures, and test a heavy frame before rendering the sequence.
Recorded Redshift jobs on iRender multi-GPU servers.
On iRender you rent a whole server with 2x, 4x or 8x RTX 5090 or RTX 4090 GPUs, with Cinema 4D and Redshift pre-installed; Prime members get activated Cinema 4D and Redshift licenses. Related: Redshift multi-GPU rendering and Redshift proxies. Real render times are in our Redshift benchmark, and plans are on the Cinema 4D Redshift render farm page.
6. Redshift out-of-core FAQ
What is out-of-core rendering in Redshift?
It lets Redshift render scenes whose geometry and textures do not fit in GPU memory by keeping data in system RAM and moving what is needed over PCIe. It keeps big scenes rendering, but excessive out-of-core access can slow renders considerably.
Does Redshift combine VRAM from several GPUs?
No. Maxon support states Redshift does not combine VRAM across GPUs; each GPU can only use its own memory, so every card must hold the scene.
Can OpenVDB volumes go out-of-core in Redshift?
No. According to Maxon support, Redshift cannot currently store volume grids such as OpenVDB out-of-core, so volumes must fit in GPU memory.
How do I know if Redshift is rendering out-of-core?
Watch the Feedback Display and log: they show memory per module and how much texture data is uploaded over PCIe. Large uploads compared with the texture cache size mean textures are being streamed.
What does the Redshift Texture Processor do?
It converts textures to Redshift’s own format ahead of render time, stored next to the source file. Otherwise Redshift converts them automatically at render time and keeps them in the local cache folder.
Should I increase the texture cache?
Usually not. Maxon describes 15% as sensible for most scenes. For texture-heavy scenes with performance issues, Maxon suggests raising the CPU texture cache from 4 GB to 8 GB or more.
