Texture Cache & Memory

A) QUICK START

What is Redshift caching?

When you render, Redshift converts your textures (JPG, PNG, EXG) into optimized .tx 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 .tx 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 .tx 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 .tx format first. The .tx format is optimized for GPU rendering and allows Redshift to stream large textures efficiently without running out of memory.

The cache system stores these .tx 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 .tx 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 brick_wall.tx stored?”\

3. Decision point:

   1. If .tx exists in cache → Uses it immediately

   2. If .tx doesn't exist → Converts brick_wall.jpg to brick_wall.tx and saves to the cache folder

4. Renders using .tx file - The GPU only ever sees the .tx version

Important: The original JPG/PNG/EXR files are never touched or modified. Redshift reads them, creates a separate .tx 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

• tx 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 .tx yourself using TextureProcessor tool

• You decide where .tx files are stored (typically next to source textures)

• You control exactly when conversion happens

• You turn off automatic cache copying

When to use manual:

• Working on a render farm (need identical .tx files on all machines)

• Team environment (everyone shares the same .tx files)

• Very large projects (want precise control over storage locations)

• Network rendering (want .tx 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 .tx file creation

Using this method is a two-step procedure. Step 1 - you manually convert your textures to .tx files. Step 2 - You tell Redshift to use your own .tx files instead of automatically pre-converting them at render time.

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 where these .tx files live and when they get created.

When to Use This Workflow:
Multiple machines need identical .tx 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 .tx files will appear right next to your original textures.
  
  Important: Specify color space correctly
  For color textures (diffuse, albedo):
   

  redshiftTextureProcessor.exe *.jpg -cs "sRGB"

  
  For data textures (bump, normal, roughness):
   

  redshiftTextureProcessor.exe *.jpg -cs "Linear"

  
  After doing all of this:

  • brick_wall.jpg becomes brick_wall.tx (same folder)

  • metal_rough.png becomes metal_rough.tx (same folder)

  • Original files stay untouched

Step 2: Tell Redshift to Use Your .tx Files

There are two ways to tell Redshift to use your own .tx files.

Option A: Keep your .jpg paths in materials, but disable copying

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

2. Go to Render Settings → Sampling → Texture Sampling

3. Turn OFF “Copy Pre-Converted Textures to Cache Folder”

What happens when you do this?

• Material says: “use brick_wall.jpg”

• Redshift looks next to brick_wall.jpg

• Finds brick_wall.tx already there

• Uses brick_wall.tx directly (no copying, no converting)

Option B: Point materials directly to .tx files

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

2. Example: Change D:\Textures\brick_wall.jpg to D:\Textures\brick_wall.tx

What happens when you do this?

• Material says: “use brick_wall.tx”

• Redshift uses that .tx file directly

(Optional) Step 3: Verify It's Working

Check the log file when rendering:

You should see something like:

NOT:

If Redshift is still ‘converting’:

• Check “Copy Pre-Converted Textures to Cache Folder” is OFF

• Verify .tx files are in the same folder as source textures

• Check .tx filenames exactly match source names

Where to Store Your .tx Files

For solo work:

Store .tx files next to source textures:

For render farms:

Store .tx files on shared network drive:

All render nodes access the same .tx files. Turn OFF “Copy Pre-Converted Textures to Cache Folder” on all machines.

Additional option: For teams with fast local drives:

Each artist stores .tx files locally:

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 “Linear” for bump, normal, roughness, metalness maps

• Mistake: .tx filename doesn't match source
  Problem: You have brick_wall.jpg but created brick_wall_diffuse.tx
  Fix: .tx must have exact same base name as source file

• Mistake: .tx files in cache folder, not project folder
  Problem: You manually put .tx files in C:\Users\...\Redshift\Cache\
  Fix: Never put your .tx files in the cache folder. Keep them with your project textures.

• Mistake: Forgot to turn off copying
  Problem: Redshift copies your .tx files to cache anyway (wasting time)
  Fix: Turn OFF “Copy Pre-Converted Textures to Cache Folder” when using manual workflow

Quick Comparison: Auto vs Manual

In short, regarding the manual workflow: Once you've converted your textures and disabled cache copying, you're done. Redshift can use your .tx files directly.

If you need to update a texture:

• Update the source .jpg file

• Re-run TextureProcessor on that file

• New .tx file replaces old one

• Next render uses updated version

C) REFERENCE: Understanding the cache settings/Parameters

Main parameters:

Cache Folder Path (Edit → Preferences → Redshift → Cache)

• What it is: The folder where Redshift stores converted .tx files

• Default location: C:\Users\[YourName]\AppData\Local\Redshift\Cache

• Why change it: Move to faster SSD, or to drive with more space

• 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 → Redshift → Cache)

• What it is: Maximum total size of the cache folder

• Default: 32 GB

• How it works: When cache exceeds this size, Redshift automatically deletes oldest unused .tx files from previous projects

• Important: Your current scene is never limited - if you need 50GB of textures right now, Redshift caches all 50GB. The limit only triggers cleanup of old project files.

• 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 .tx file you already created manually
  Default: ON (enabled)

• When ON: If Redshift finds mytexture.tx next to mytexture.jpg, it copies that .tx into the cache folder and renders from the cache copy

• When OFF: If Redshift finds mytexture.tx 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 .tx files on storage that's as fast as (or faster than) your cache location

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 .tx files: Stored next to source textures in project folder

• Result: Redshift uses your .tx 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 .tx files: Pre-converted, stored on network drive

• Result: Redshift copies your .tx 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 deleted .tx file? (D2)
• Render shows old texture: → Delete .tx from cache (D2)
• Cache folder ignored: → Check for environment variable (D1)
• macOS cache error: → Delete redshift folder, restart (D1)
• Farm renders inconsistent: → Same-named .tx 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 (Linear). One looks correct, the other is washed out or wrong.

Why: Redshift creates one .tx file per source image. The first use determines the color space baked into the .tx file. When you reuse that same .jpg with a different color space, Redshift uses the already-created .tx with the wrong color space.

The fix: Duplicate and rename: wood.jpg → wood_bump.jpg Delete the old .tx from cache, render again.

Prevention: Always use unique names: wood_diffuse.jpg, wood_bump.jpg, wood_roughness.jpg

Texture is black/missing

The problem: Material points directly to brick.tx, 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 .tx file using TextureProcessor

Updated .jpg but render shows old version

The problem: You edited fabric.jpg, but renders still show the old version.

Why: The old fabric.tx is still in the cache. Redshift doesn't detect the .jpg was updated.

The fix: Delete fabric.tx from your cache folder, render again. Redshift will reconvert from the updated .jpg.

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: Delete the wrong .tx file and reconvert:

Color textures (sRGB):

Data textures (Linear):

Rule: If it looks like a picture → sRGB. If it's data/numbers → Linear.

D3 - Render Farm Issues

Same texture name, different folders, wrong results

The problem: You have metal.tx in two folders with different settings. Works locally, but farm renders look wrong.

Why: Scene path remapping on the farm loads the wrong metal.tx.

The fix: Use unique names: metal_color.tx, metal_bump.tx, metal_roughness.tx

Flickering or corrupt textures on farm

The problem: Your .tx files are stored on a shared network drive (like Z:\Assets\Textures\). A render node starts rendering before the .tx 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.

The fix:

Basic manual check (small projects): Before submitting to farm, navigate to your shared .tx folder and:

1. Right-click on .tx 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 .tx 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 .tx files ✅ Force Redshift to rebuild .tx 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 .tx files might be in the cache folder

How to clean safely:

1. Check cache folder for any custom .tx 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 Linear (or vice versa) Fix: Delete .tx, reconvert with correct flag

Filename doesn't match

Problem: brick_wall.jpg but you created brick_wall_diffuse.tx Fix: .tx filename must exactly match the source: brick_wall.jpg → brick_wall.tx

Saved .tx in cache folder

Problem: You manually put .tx 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"

• Data textures: *_roughness.jpg -cs "Linear"

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.tx. When TextureProcessor converts both, the second one overwrites the first. Redshift can't tell which .tx belongs to which source file.

Example of the problem:

Now your material points to brick_color.jpg, but Redshift finds brick.tx 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):

Bad (conflicting names):

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