Texture Cache & Memory

Netinho Da Costa
Netinho Da Costa
  • Updated

 

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:

  1. Redshift sees texture assignment - Your material points to brick_wall.jpg

  2. Checks cache folder - “Do I already have a converted brick_wall stored?”\

  3. Decision point:

    1. f the converted file exists in cache → Uses it immediately
    2. If it doesn't exist → Converts brick_wall.jpg to .rstexbin and saves it to the cache folder
  4. 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/redshiftTextureProcessor

  • Open 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)

 

  1. Keep your materials pointing to .jpg files as normal

  2. Go to Render Settings → Sampling → Texture Sampling

  3. 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

 

  1. Change your material texture paths from .jpg to .rstexbin

  2. 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.rstexbin

Everyone 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 maps

  • Mistake: 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 file

  • Mistake: 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:

  1. Check if you have write permissions on /Users/[username]/Library/Application Support/Redshift/

  2. If that doesn't work: Quit C4D, delete the entire /Users/[username]/redshift/ folder, restart C4D

  3. Redshift 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:

  1. Right-click on .rstexbin files → Properties (Windows) or Get Info (macOS)

  2. Check file size is not 0 bytes

  3. 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.

  1. Check cache folder for any custom .rstexbin files you saved there (move them out first)

  2. Close Cinema 4D

  3. Delete everything inside cache folder (not the folder itself)

  4. Restart C4D

  5. 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.

Was this article helpful?

/

Comments

0 comments

Please sign in to leave a comment.