A) QUICK START
What is Redshift caching?
When you render, Redshift converts your textures (JPG, PNG, EXG) into optimized .rstexbin files and stores them in a folder on your computer. This “texture cache” keeps these converted files so your second render starts faster than your first.
There are two workflows for managing the Redshift texture cache:
Workflow 1 - Default (automatic) - Redshift handles everything
You add textures to materials like normal
Redshift converts them in the background
Works immediately, no setup needed
Recommended if you're learning or working solo
Workflow 2 - Manual Conversion - You control the .rstexbin file creation
You convert textures yourself using a separate tool
Gives you control over where files are stored
Preferred for render farms or team workflows
See “Manual .rstexbin File Pre-Conversion” section below
Common settings you might want to adjust:
-
Cache folder location - Move it to a faster drive if your system drive is slow
In Cinema 4D you can find the cache location here:
Step 1 - Go to the preferences panel:
Inside the preferences panel, you will find the cache folder location inside the Renderer → Redshift tab. This section will contain the Cache folder path option (inside the CACHE section)
Texture Cache Max GB (0=unlimited) - Defaults to 32GB. This cache size limit automatically cleans up old project files (You will find this just below the cache folder location in the same section in the screenshot above).
-
“Copy Pre-Converted Textures to Cache Folder” checkbox (in Render Settings → Sampling tab) - This is for advanced users who want manual control over texture caching (explained in the workflows section below)
B) THE BASICS
A detailed overview explaining what the Redshift cache feature does
The core concept: Redshift never renders your JPG, PNG, or EXR files directly. It always converts them to its .rstexbin format first. The .rstexbin format is optimized for GPU rendering and allows Redshift to stream large textures efficiently without running out of memory.
The cache system stores these .rstexbin files so Redshift doesn't have to reconvert the same texture every time you render. On your first render: conversion happens. Every render after: uses the stored .rstexbin file.
Workflow 1 - Default (automatic) - Redshift handles everything
Every time you render, this sequence happens:
Redshift sees texture assignment - Your material points to brick_wall.jpg
Checks cache folder - “Do I already have a converted brick_wall stored?”\
-
Decision point:
- f the converted file exists in cache → Uses it immediately
- If it doesn't exist → Converts brick_wall.jpg to .rstexbin and saves it to the cache folder
- Renders using the .rstexbin file - The GPU only ever sees the .rstexbin version
Important: The original JPG/PNG/EXR files are never touched or modified. Redshift reads them, creates a separate .rstexbin file, and always renders from that.
More insights on choosing between automatic and manual workflows
Automatic (default workflow):
Redshift manages everything - you just assign textures normally
Conversions happen automatically during render preparation
.rstexbin files are stored in Redshift's cache folder
Cache automatically cleans up old files when it reaches size limit
When to use automatic:
You're learning Redshift
Working solo on your own machine
Textures change frequently during look development
You want the simplest possible setup
Manual (advanced workflow):
You convert textures to .rstexbin yourself using the TextureProcessor tool
The .rstexbin files are stored next to your source textures
You control exactly when conversion happens and with which settings
You choose whether Redshift copies them to the cache or reads them in place
When to use manual:
Working on a render farm (need identical .rstexbin files on all machines)
Team environment (everyone shares the same .rstexbin files)
Very large projects (want precise control over storage locations)
Network rendering (want .rstexbin files on fast shared storage)
The key difference: Automatic is "set and forget.” Manual is “I need precise control over where and when conversions happen.”
Workflow 2 - Manual Conversion - You control the .rstexbin file creation
Using this method is a two-step procedure. Step 1 - you manually convert your textures to .rstexbin files. Step 2 - you decide whether Redshift should copy those files into its cache or read them directly from where they are. Redshift finds and uses your converted files automatically as long as they sit next to the source texture with the same name.
When using this manual workflow, instead of letting Redshift convert textures automatically during render time, you convert them yourself ahead of time using a tool called TextureProcessor. You decide when these .rstexbin files get created and with which settings. They live next to your source textures.
When to Use This Workflow: Multiple machines need identical .rstexbin files (render farms), Your team shares texture libraries, You want textures on a specific fast drive, You need to control conversion settings precisely
Step 1: Convert Your Textures
Find the TextureProcessor tool:
(We also explain more about it here in the official documentation):
https://help.maxon.net/r3d/cinema/en-us/#html/Texture+Processor+Tool.html?TocPath=Texture%2520Topics%257C_____2
Windows: C:\ProgramData\redshift\bin\redshiftTextureProcessor.exe
macOS: /Applications/redshift/bin/redshiftTextureProcessor
Linux: /usr/redshift/bin/redshiftTextureProcessorOpen your command line:
Windows: Shift + right-click inside your texture folder → “Open PowerShell window here”
macOS/Linux: Open Terminal and navigate to your texture folder-
Convert all textures in the folder:
redshiftTextureProcessor.exe *.jpg
This converts every ( * ) .jpg file in the folder. The .rstexbin files will appear right next to your original textures.
Important: Specify color space correctly
For color textures (diffuse, albedo):
"C:\Program Files\Maxon Redshift 2027\bin\redshiftTextureProcessor.exe" "$PWD\*.jpg" -cs "sRGB"
For data textures (bump, normal, roughness):
r& "C:\Program Files\Maxon Redshift 2027\bin\redshiftTextureProcessor.exe" "$PWD\*.jpg" -cs "Raw"
After doing all of this:- brick_wall.jpg gets a brick_wall.rstexbin next to it (same folder)
- metal_rough.png gets a metal_rough.rstexbin next to it (same folder)
- Original files stay untouched
Step 2: Tell Redshift to Use Your .rstexbin Files
Redshift automatically picks up your .rstexbin files when they sit next to the source textures. The only choice left is whether it copies them to the local cache first.
Option A: KKeep your .jpg paths in materials (recommended)
Keep your materials pointing to .jpg files as normal
Go to Render Settings → Sampling → Texture Sampling
-
Set “Copy Pre-Converted Textures to Cache Folder” to match your storage:
- ON = your textures are on a slower drive or network share than your cache. Redshift copies them to the local cache first.
- OFF = your textures are on a drive as fast as (or faster than) the cache. Redshift reads them in place.
What happens when you do this?
- Material says: “use brick_wall.jpg”
- Redshift looks next to brick_wall.jpg
- Finds brick_wall.rstexbin already there
- Uses it directly (no converting; with copying OFF it also skips the copy)
Option B: Point materials directly to .rstexbin files
Change your material texture paths from .jpg to .rstexbin
Example: Change D:\Textures\brick_wall.jpg to D:\Textures\brick_wall.rstexbin
What happens when you do this?
Material says: “use brick_wall.rstexbin”
Redshift uses that .rstexbin file directly
(Optional) Step 3: Verify It's Working
Check the log file when rendering. If you see a line like this, Redshift did NOT find your converted file and converted it again:
Texture file 'D:\Project\Textures\brick_wall.jpg' conversion triggered, because: cache file was not found!
If no “conversion triggered” line appears for that texture, your pre-converted file was used.
If Redshift is still ‘converting’:
- Verify the .rstexbin files are in the same folder as the source textures
- Check the .rstexbin base name exactly matches the source name
- Check you converted with the same options the log recommends (color space, etc.)
Where to Store Your .rstexbin Files
For solo work:
For solo work: store .rstexbin files next to source textures:
D:\Project\Textures\
brick_wall.jpg
brick_wall.rstexbin
metal_plate.jpg
metal_plate.rstexbin
For render farms:
For render farms: store .rstexbin files on the shared network drive:
Z:\SharedTextures\
brick_wall.jpg
brick_wall.rstexbin
All render nodes use the same converted files. Usually leave “Copy Pre-Converted Textures to Cache Folder” ON: a network drive is normally slower than each node's local SSD cache, which is exactly the case this option is for. Only turn it OFF if your network storage is as fast as the local drives.
Additional option: For teams with fast local drives:
For teams with fast local drives, each artist stores .rstexbin files locally:
D:\TextureLibrary\
brick_wall.jpg
brick_wall.rstexbinEveryone pre-converts textures once. Copy setting can stay ON or OFF depending on your setup.
Common Mistakes & How to Avoid Them
Mistake: Wrong color space during conversion
Problem: Roughness map converted with sRGB looks washed out
Fix: Always use -cs "Raw" for bump, normal, roughness, metalness mapsMistake: converted filename doesn't match source
Problem: You have brick_wall.jpg but the converted file is called brick_wall_diffuse.rstexbin
Fix: the .rstexbin must have exactly the same base name as the source fileMistake: converted files in the cache folder, not the project folder
Problem: You manually put .rstexbin files in C:\Users...\Redshift\Cache\
Fix: Never put your own .rstexbin files in the cache folder. Keep them next to your project textures.Mistake: wrong copy setting for your storage
Problem: Your textures are on a fast local SSD and Redshift copies them to a cache on the same (or a slower) drive, which wastes time and disk space
Fix: Turn OFF “Copy Pre-Converted Textures to Cache Folder” when your textures are on storage as fast as your cache. Leave it ON when they're on a slower drive or network share.
Quick Comparison: Auto vs Manual
Question |
Automatic |
Manual |
|---|---|---|
Who converts textures? |
Redshift (during render) |
You (before render) |
Where are the converted files? |
Cache folder |
Next to your source textures |
When to use? |
Solo work, learning |
Teams, farms, control |
Setup time |
Zero |
Approx 5 minutes |
Control level |
None |
Complete |
In short, regarding the manual workflow: Once you've converted your textures and set the copy option to match your storage, you're done. Redshift picks up your .rstexbin files automatically.
If you need to update a texture:
- Update the source .jpg file
- Re-run TextureProcessor on that file
- New .rstexbin file replaces old one
- Next render uses updated version
C) REFERENCE: Understanding the cache settings/Parameters
Main parameters:
Cache Folder Path (Edit → Preferences → Renderer → Redshift → Cache)
- What it is: The folder where Redshift stores converted textures (.rstexbin, in the Textures subfolder), plus compiled shaders and mesh caches
- Default location: C:\Users[YourName]\AppData\Local\Redshift\Cache
- Why change it: Move to faster SSD, or to drive with more space
- Changes to this setting only take effect after restarting Cinema 4D.
- Important: Environment variable REDSHIFT_CACHEPATH overrides this setting if it exists on your system. If your cache folder appears greyed out or isn't being used, see Section D1 - Troubleshooting Environment Variables.
Texture Cache Max GB (Edit → Preferences → Renderer → Redshift → Cache)
- What it is: Maximum total size of the cache folder
- Default: 32 GB
- How it works: Each time Redshift starts, it checks the cache size. If it's over the limit, Redshift deletes the least recently used files until it's under. This goes by when a file was last used, not by which project it came from.
- Important: Your current scene is never limited - if you need 50GB of textures right now, Redshift caches all 50GB.
- Important: the environment variable REDSHIFT_TEXTURECACHEBUDGET overrides this setting if it exists on your system (same as REDSHIFT_CACHEPATH does for the folder).
- Changes to this setting only take effect after restarting Cinema 4D.
- Set to 0: Unlimited size (no automatic cleanup)
“Copy Pre-Converted Textures to Cache Folder” (Render Settings → Sampling tab)
- What it is: Controls what happens when Redshift finds a .rstexbin file you already created manually
- Default: ON (enabled)
- When ON: If Redshift finds mytexture.rstexbin next to mytexture.jpg, it copies that .rstexbin into the cache folder and renders from the cache copy
- When OFF: If Redshift finds mytexture.rstexbin next to mytexture.jpg, it uses it directly from that location (no copying)
- Why it exists: Assumes cache folder is faster than source location (e.g., cache on SSD, textures on network drive)
- Turn it OFF when: You're manually managing .rstexbin files on storage that's as fast as (or faster than) your cache location
Common Workflows: Settings in Context
Based on what we know now, let’s take a look at a few contexts/workflows and how these settings relate.
Scenario 1: Default automatic workflow
- Cache folder: Default location
- Cache size: 32 GB
- Copy setting: ON (default)
- Result: Redshift auto-converts everything, stores in cache, cleans up automatically
Scenario 2: Manual workflow with local storage
- Cache folder: Only used for textures you haven't pre-converted (and for shaders)
- Cache size: Only matters for those
- Copy setting: OFF
- Your .rstexbin files: Stored next to source textures in project folder
- Result: Redshift uses your .rstexbin files directly from the project folder
Scenario 3: Manual workflow with cache copying
- Cache folder: Fast SSD
- Cache size: 64 GB (larger for active projects)
- Copy setting: ON
- Your .rstexbin files: Pre-converted, stored on network drive
- Result: Redshift copies your .rstexbin files from network to fast local cache, renders from cache
Common Workflows: Settings in Context:
Bases on what we know now, let’s take a look at a few contexts/workflows and how these settings relate.
Scenario 1: Default automatic workflow
Cache folder: Default location
Cache size: 32 GB
Copy setting: ON (default)
Result: Redshift auto-converts everything, stores in cache, cleans up automatically
Scenario 2: Manual workflow with local storage
Cache folder: Not relevant (not used)
Cache size: Not relevant (not used)
Copy setting: OFF
Your .rstexbin files: Stored next to source textures in project folder
Result: Redshift uses your .rstexbin files directly from project folder, never touches cache
Scenario 3: Manual workflow with cache copying
Cache folder: Fast SSD
Cache size: 64 GB (larger for active projects)
Copy setting: ON
Your .rstexbin files: Pre-converted, stored on network drive
Result: Redshift copies your .rstexbin files from network to fast local cache, renders from cache
D) TROUBLESHOOTING & ADVANCED ISSUES
Quick Troubleshooting Checklist
- Texture looks washed out/dark/wrong: → Same .jpg used with different color spaces? (see D2 below) → Wrong color space in TextureProcessor? (D5)
- Texture is black/missing: → Material points to a deleted .rstexbin file? (D2) [VERIFY: remove if Option B is removed]
- Render shows old texture: → Clear the texture cache (D2)
- Cache folder ignored: → Check for environment variable (D1)
- macOS cache error: → Delete redshift folder, restart (D1)
- Farm renders inconsistent: → Same-named .rstexbin files in different folders? (D3) → Network sync issues? (D3)
This section below covers problems you might encounter and how to fix them. If something's not working as expected, start here.
D1 - Cache Settings Not Working
Cache folder location is ignored
The problem: You changed the cache folder in preferences, but Redshift ignores it and uses a different location.
Why: An environment variable called REDSHIFT_CACHEPATH is set on your computer. Environment variables override Cinema 4D's settings.
The fix: Remove or change the REDSHIFT_CACHEPATH environment variable on your system, then restart Cinema 4D.
Check your Redshift log to verify the correct cache path is being used: https://support.maxon.net/hc/en-us/articles/6772618851485-Step-by-Step-Finding-Your-Redshift-Log-File
“Failed to create cache path” (macOS)
The problem: macOS says Redshift can't create the cache folder.
The fix:
Check if you have write permissions on
/Users/[username]/Library/Application Support/Redshift/If that doesn't work: Quit C4D, delete the entire
/Users/[username]/redshift/folder, restart C4DRedshift recreates the folder automatically
Warning: Deleting the folder clears your cache. First render after will be slower.
D2 - Texture Looks Wrong
Same texture file used twice looks different
The problem: You use wood.jpg for both diffuse (sRGB) and bump (Raw). One looks correct, the other is washed out or wrong.
Why: When you pre-convert manually, there is only ONE .rstexbin per source image (same name, same folder), so it can only hold one color space. If you use that same .jpg as both color and bump, one of the two uses gets the wrong color space.
The fix: Duplicate and rename: wood.jpg → wood_bump.jpg hen convert each one with its own color space (-cs "sRGB" for wood.jpg, -cs "Raw" for wood_bump.jpg).
Prevention: Always use unique names: wood_diffuse.jpg, wood_bump.jpg, wood_roughness.jpg
Texture is black/missing
The problem: Material points directly to rick.rstexbin, but that file was deleted or moved. Redshift won't fall back to the .jpg.
The fix: Option 1: Change material to point back to brick.jpg Option 2: Recreate the .rstexbin file using TextureProcessor
Updated .jpg but render shows old version
The problem: You edited fabric.jpg, but renders still show the old version.
Why: An old converted version may still be used.
The fix: Clear the texture cache and render again. In Cinema 4D: press Shift+C, type "clear", and run "Clear Baked Textures" (this clears only the current project's textures). If you pre-converted manually, re-run the TextureProcessor on that file with -noskip.
Pre-converted texture has wrong color space
The problem: You used TextureProcessor with the wrong -cs flag. Roughness looks washed out, or diffuse looks too dark.
The fix: Reconvert with the correct flag. -noskip forces reconversion even if the tool thinks nothing changed.
Color textures (sRGB):
& "C:\Program Files\Maxon Redshift 2027\bin\redshiftTextureProcessor.exe" "$PWD\wood_diffuse.jpg" -cs "sRGB" -noskip
Data textures (Linear):
& "C:\Program Files\Maxon Redshift 2027\bin\redshiftTextureProcessor.exe" "$PWD\wood_roughness.jpg" -cs "Raw" -noskip& "C:\Program Files\Maxon Redshift 2027\bin\redshiftTextureProcessor.exe" "$PWD\wood_bump.jpg" -cs "Raw" -noskip
Rule: If it looks like a picture → sRGB. If it's data/numbers → Raw.
D3 - Render Farm Issues
Same texture name, different folders, wrong results
The problem: You have metal.rstexbin in two folders with different settings. Works locally, but farm renders look wrong.
Why: Scene path remapping on the farm loads the wrong metal.rstexbin.
The fix: Use unique names: metal_color.jpg, metal_bump.jpg, metal_roughness.jpg (their .rstexbin files then get unique names too)
Flickering or corrupt textures on farm
The problem: Your .rstexbin files are stored on a shared network drive (like Z:\Assets\Textures). A render node starts rendering before the .rstexbin file finishes copying or syncing to that network location. The render node reads incomplete or corrupt data, causing flickering textures or material glitches across frames.tches across frames.
The fix:
Basic manual check (small projects): Before submitting to farm, navigate to your shared .rstexbin folder and:
Right-click on .rstexbin files → Properties (Windows) or Get Info (macOS)
Check file size is not 0 bytes
Try opening the file in a text editor - if it opens instantly without errors, it's not locked
For larger projects/teams: This requires pipeline-level coordination. Work with your render farm administrator or technical director to ensure .rstexbin files are fully synced before render submission begins. Most render management software can validate file sync as part of pre-flight checks.
D4 - Cleaning the Cache
When to clean:
✅ Low on disk space
✅ Corrupt renders from bad cached .rstexbin files
✅ Force Redshift to rebuild .rstexbin from updated .jpg files
✅ After GPU hardware upgrade
When NOT to clean:
❌ Right before a deadline (first render after will be slow)
❌ While rendering (can crash)
❌ If custom .rstexbin files might be in the cache folder
How to clean safely:
Easiest way: in Cinema 4D press Shift+C, type "clear", and run "Clear Baked Textures". It removes only the current project's cached textures and leaves other projects alone. "Clear Memory Caches" only frees RAM, not disk. Use the manual steps below if you want to wipe everything.
Check cache folder for any custom .rstexbin files you saved there (move them out first)
Close Cinema 4D
Delete everything inside cache folder (not the folder itself)
Restart C4D
First render will be slower (reconverting textures)
Cache folder locations:
Windows:
C:\Users\[YourName]\AppData\Local\Redshift\Cache\macOS:
/Users/[username]/Library/Application Support/Redshift/TextureCache/Linux:
~/.redshift/cache/
D5 - TextureProcessor Mistakes
Wrong color space
Problem: Converted with -cs "sRGB" when it should be Raw (or vice versa)
Fix: Delete the .rstexbin, reconvert with correct flag
Filename doesn't match
Problem: brick_wall.jpg but you created brick_wall_diffuse.rstexbin
Fix: the converted file must exactly match the source name: brick_wall.jpg → brick_wall.rstexbin
Saved .rstexbin in cache folder
Problem: You manually put .rstexbin files in C:\Users\...\Redshift\Cache\
Fix: Move them to your project texture folder immediately. Cache is for Redshift's automatic management only.
Batch converted without specifying color space
Problem: Ran *.jpg without -cs flag, now bump/roughness maps look wrong
Fix: Separate conversions:
Color textures:
*_diffuse.jpg -cs "sRGB"
Example: & "C:\Program Files\Maxon Redshift 2027\bin\redshiftTextureProcessor.exe" "$PWD\*_diffuse.jpg" -cs "sRGB"Data textures:
*_roughness.jpg -cs "Raw"Example: & "C:\Program Files\Maxon Redshift 2027\bin\redshiftTextureProcessor.exe" "$PWD\*_roughness.jpg" -cs "Raw"
Naming conflicts with different file extensions
Problem: You have brick.jpg and brick.exr in the same folder. TextureProcessor runs, but one texture looks wrong or missing.
Why it's wrong: Both brick.jpg and brick.exr create brick.rstexbin. When TextureProcessor converts both, the second one overwrites the first. Redshift can't tell which .rstexbin belongs to which source file.
Example of the problem:
D:\Textures\
brick.jpg → creates brick.rstexbin
brick.exr → also creates brick.rstexbin (overwrites the first one!)
Now your material points to brick_color.jpg, but Redshift finds brick.rstexbin which actually came from brick_displacement.exr. Wrong texture loads.
The fix: Use unique base names for all textures, regardless of extension:
Good (unique names):
D:\Textures\
brick_color.jpg → creates brick_color.rstexbin
brick_displacement.exr → creates brick_displacement.rstexbin
Bad (conflicting names):
D:\Textures\
brick.jpg → creates brick.rstexbin
brick.exr → also creates brick.rstexbin ❌
D6 - Performance Issues
First render is very slow
The problem: Your first render takes significantly longer than expected - sometimes minutes just to start rendering.
Why: Redshift is converting all your textures to its .rstexbin format in the background. This conversion happens during the “Preparing Scene” phase before actual rendering begins. Depending on how many textures you have and their resolution, this can take considerable time.
What you'll see:
Long “Preparing Scene” phase on first render
CPU usage spikes during this phase
Subsequent renders of the same scene start much faster
The fix: This is normal behavior for the automatic workflow. Second and subsequent renders will be fast because the .rstexbin files are already created.
To avoid this delay entirely: Use the manual workflow (Section B - Workflow 2) and pre-convert all textures using TextureProcessor before you start rendering.
Comments
0 comments
Please sign in to leave a comment.