纹理缓存与内存

Netinho Da Costa
Netinho Da Costa
  • 更新

A）快速入门

什么是 Redshift 的纹理缓存？

在渲染时，Redshift 会将您的纹理文件（JPG、PNG、EXR）转换为经过优化的 .tx 文件，并将其存储在您计算机上的某个文件夹中。
这个【纹理缓存】会保存这些已转换的文件，使得第二次渲染相比第一次启动得更快。

管理 Redshift 纹理缓存的两种工作流程

工作流程 1：默认（自动）流程 —— 由 Redshift 全权管理

  • 您像平常一样将纹理添加到材质中

  • Redshift 会在后台自动进行转换

  • 即刻生效，无需任何额外设置

  • 推荐给正在学习或单人工作的用户

工作流程 2：手动转换 —— 由您控制 .tx 文件的生成

  • 您使用独立工具自行转换纹理

  • 您可以决定 .tx 文件的存储位置

  • 更适合渲染农场或团队协作流程

  • 详见下文【手动 .tx 文件预转换】章节

常见可调整设置

缓存文件夹位置

如果您的系统盘较慢，可将缓存移动到更快的磁盘。

在 Cinema 4D 中，您可以在以下位置找到缓存路径：

步骤 1：打开首选项面板

在首选项面板中，进入
渲染器 → Redshift → Cache
在该区域中可以找到【Cache Folder Path】缓存路径设置（位于 CACHE 区域内）。

Texture Cache Max GB（0 = 不限制）

  • 默认值：32 GB

  • 该缓存大小限制会在达到上限时，自动清理旧项目生成的缓存文件

  • 该设置位于缓存路径选项下方（见上方截图所示位置）

“Copy Pre-Converted Textures to Cache Folder” 复选框

（渲染设置 → Sampling 选项卡）

  • 该选项主要面向需要手动控制纹理缓存的高级用户

  • 具体说明请参见下文各工作流程说明
     

B）基础概念

Redshift 缓存机制的核心原理

Redshift 不会直接使用 JPG、PNG 或 EXR 文件进行渲染。
所有纹理都会先被转换为 .tx 格式。

.tx 是一种专为 GPU 渲染优化的格式，允许 Redshift 高效地流式加载大尺寸纹理，而不会轻易耗尽显存。

缓存系统的作用，是保存这些 .tx 文件，避免在每次渲染时都重复转换同一张纹理。

  • 第一次渲染：发生转换

  • 之后的所有渲染：直接复用已存在的 .tx 文件

工作流程 1：默认（自动）流程 —— Redshift 全自动处理

每次渲染时，都会发生以下流程：

  1. Redshift 检测到纹理被使用
    材质指向 brick_wall.jpg

  2. 检查缓存文件夹
    “我是否已经有 brick_wall.tx？”

  3. 判断结果：

    • 如果缓存中存在 .tx → 直接使用

    • 如果不存在 → 将 brick_wall.jpg 转换为 brick_wall.tx 并保存到缓存目录

  4. 使用 .tx 文件进行渲染
    GPU 始终只接触 .tx 文件

重要说明
原始 JPG、PNG、EXR 文件永远不会被修改。
Redshift 只是读取它们，生成独立的 .tx 文件，并始终基于 .tx 进行渲染。

自动流程与手动流程的选择建议

自动流程（默认）

  • Redshift 自动管理全部过程

  • 转换发生在渲染准备阶段

  • .tx 文件存储于缓存目录

  • 缓存达到上限时会自动清理旧文件

适用场景：

  • 您正在学习 Redshift

  • 单机、个人项目

  • 材质和纹理频繁变动

  • 希望配置尽可能简单

手动流程（高级）

  • 使用 TextureProcessor 工具自行转换 .tx

  • .tx 文件通常与原始纹理放在同一目录

  • 完全控制转换时机

  • 关闭自动缓存复制

适用场景：

  • 渲染农场

  • 团队协作

  • 超大型项目

  • 网络渲染

  • 需要精确控制存储结构

核心区别一句话总结：
自动流程是“设置完就不用管”；
手动流程是“我需要完全掌控何时、何地、如何生成”。

工作流程 2：手动转换

该流程包含两个步骤：

  • 步骤 1：手动将纹理转换为 .tx

  • 步骤 2：告知 Redshift 使用您生成的 .tx 文件，而非自动转换

何时使用该流程

  • 多台机器需要使用完全一致的 .tx 文件（渲染农场）

  • 团队共享纹理库

  • 需要将纹理放在指定的高速磁盘

  • 希望精确控制转换参数

步骤 1：转换纹理

TextureProcessor 工具位置

官方文档说明：
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

打开命令行

  • Windows：在纹理文件夹中按住 Shift 右键 → 选择“在此处打开 PowerShell 窗口”

  • macOS / Linux：打开终端并进入纹理所在目录

批量转换纹理

redshiftTextureProcessor.exe *.jpg

该命令会转换当前文件夹下所有 .jpg 文件，并在同一目录生成对应的 .tx 文件。

重要：正确指定色彩空间

颜色贴图（Diffuse / Albedo）：

redshiftTextureProcessor.exe *.jpg -cs "sRGB"

数据贴图（Bump / Normal / Roughness）：

redshiftTextureProcessor.exe *.jpg -cs "Linear"

转换结果示例

  • brick_wall.jpg → brick_wall.tx

  • metal_rough.png → metal_rough.tx

原始文件保持不变。

步骤 2：让 Redshift 使用您的 .tx 文件

方式 A：材质仍指向 .jpg，关闭复制

  • 材质中仍使用 .jpg 路径

  • 打开【渲染设置 → Sampling → Texture Sampling】

  • 关闭“Copy Pre-Converted Textures to Cache Folder”

结果：

  • 材质指向 brick_wall.jpg

  • Redshift 在同目录找到 brick_wall.tx

  • 直接使用该 .tx 文件，不复制、不转换

方式 B：材质直接指向 .tx

  • 将材质路径从 .jpg 改为 .tx

  • 例如：
    D:\Textures\brick_wall.jpg → D:\Textures\brick_wall.tx

结果：

  • Redshift 直接使用指定的 .tx 文件

（可选）步骤 3：验证是否生效

查看渲染日志，您应看到类似：

Texture: brick_wall.tx (using existing file)

而不是：

Texture: brick_wall.jpg (converting to cache...)

.tx 文件存储建议

单人项目

D:\Project\Textures\
brick_wall.jpg
brick_wall.tx
metal_plate.jpg
metal_plate.tx

渲染农场 / 团队

Z:\SharedTextures\
brick_wall.jpg
brick_wall.tx

所有渲染节点访问同一目录，并关闭复制选项。

常见错误与避免方法

错误：色彩空间使用错误

  • 现象：粗糙度贴图看起来发灰

  • 解决：数据贴图始终使用 Linear

错误：.tx 文件名不匹配

  • 必须保持完全一致的基础名称

错误：将 .tx 放入缓存目录

  • 缓存目录仅供 Redshift 自动管理

  • 手动 .tx 请始终与项目纹理放在一起

C）参考：理解缓存设置与参数

主要参数：

缓存文件夹路径（Edit → Prefenrences → Redshift → Cache）

含义： Redshift 用于存放转换后的 .tx 文件的文件夹路径
默认位置： C:\Users\[YourName]\AppData\Local\Redshift\Cache
为什么要修改： 可移动到更快的 SSD，或移动到空间更充足的磁盘

重要： 如果您的系统中设置了环境变量 REDSHIFT_CACHEPATH，它会覆盖该设置。
如果您发现缓存路径是灰色不可编辑，或设置不生效，请参见 D1 - 排查环境变量。

Texture Cache Max GB（Edit → Preferences → Redshift → Cache）

含义： 缓存文件夹的最大总容量
默认值： 32 GB
工作方式： 当缓存超过该大小时，Redshift 会自动删除旧项目中【最早且不再使用】的 .tx 文件

重要： 该限制不会限制当前场景的需求。
例如：如果您当前场景需要 50GB 的纹理，Redshift 仍会缓存全部 50GB。
该上限只会触发对旧项目缓存的清理。

设为 0： 不限制大小（不会自动清理）

“Copy Pre-Converted Textures to Cache Folder”（Render Settings → Sampling tab）

含义： 控制当 Redshift 发现您已经手动生成了 .tx 文件时，该如何处理
默认： 开启（ON）

开启（ON）时：
如果 Redshift 在 mytexture.jpg 同目录发现 mytexture.tx，它会将该 .tx 复制到缓存目录，并从缓存副本进行渲染。

关闭（OFF）时：
如果 Redshift 在 mytexture.jpg 同目录发现 mytexture.tx，它会直接使用该位置的 .tx 文件（不复制）。

该选项存在的原因：
默认假设缓存目录比源纹理所在位置更快（例如缓存在 SSD，而纹理在网络盘）。

何时应关闭：
当您手动管理 .tx，且该存储位置与缓存盘一样快或更快时，建议关闭。

常见工作场景：结合设置理解

基于目前已知信息，我们来看几种常见场景中这些设置如何配合。

场景 1：默认自动流程

  • Cache folder：默认位置

  • Cache size：32 GB

  • Copy setting：ON（默认）

结果： Redshift 自动转换并写入缓存，达到上限后自动清理旧文件。

场景 2：本地存储的手动流程

  • Cache folder：不重要（不会被使用）

  • Cache size：不重要（不会被使用）

  • Copy setting：OFF

  • 您的 .tx 文件：与项目纹理存放在同一目录

结果： Redshift 直接从项目纹理目录使用 .tx，不触碰缓存。

场景 3：使用缓存复制的手动流程

  • Cache folder：高速 SSD

  • Cache size：64 GB（为活跃项目预留更大空间）

  • Copy setting：ON

  • 您的 .tx 文件：预转换后放在网络盘

结果： Redshift 将 .tx 从网络盘复制到本地高速缓存，再从缓存渲染。

D）排查与高级问题

快速排查清单

  • 纹理发灰 / 变暗 / 显示不对：
    → 同一 .jpg 是否以不同色彩空间被使用？（见 D2）
    → TextureProcessor 是否用错 -cs？（D5）

  • 纹理变黑 / 丢失：
    → 材质是否指向了已删除的 .tx？（D2）

  • 渲染显示旧纹理：
    → 删除缓存中的 .tx（D2）

  • 缓存路径设置无效：
    → 检查环境变量（D1）

  • macOS 缓存报错：
    → 删除 redshift 文件夹并重启（D1）

  • 农场渲染结果不一致：
    → 是否存在不同目录下同名 .tx？（D3）
    → 是否存在网络同步问题？（D3）

本章节将覆盖您可能遇到的问题及对应解决方式。若表现与预期不一致，请从这里开始排查。

D1 - 缓存设置不生效

缓存文件夹位置被忽略

问题现象： 您在首选项里修改了缓存路径，但 Redshift 仍在使用其他位置。
原因： 您的系统设置了环境变量 REDSHIFT_CACHEPATH，环境变量会覆盖 Cinema 4D 的设置。
解决方法： 删除或修改系统中的 REDSHIFT_CACHEPATH 环境变量，然后重启 Cinema 4D。

您可以通过 Redshift 日志确认实际使用的缓存路径：
https://support.maxon.net/hc/en-us/articles/6772618851485-Step-by-Step-Finding-Your-Redshift-Log-File

“Failed to create cache path”（macOS）

问题现象： macOS 提示 Redshift 无法创建缓存文件夹。
解决方法：

  • 检查您是否对以下路径拥有写入权限：
    /Users/[username]/Library/Application Support/Redshift/

  • 若仍不行：关闭 C4D，删除整个目录：
    /Users/[username]/redshift/
    然后重启 C4D

Redshift 会自动重新创建该目录。

警告： 删除该目录会清空缓存。删除后第一次渲染会更慢。

D2 - 纹理显示异常

同一张纹理文件被用两次，但效果不同

问题现象： 您将 wood.jpg 同时用于漫反射（sRGB）与凹凸（Linear），其中一个看起来发灰或不正确。
原因： Redshift 对每个源图像只生成一个 .tx 文件。首次使用时决定了写入 .tx 的色彩空间。
当同一 .jpg 之后以另一种色彩空间再次被使用时，Redshift 会继续使用已存在的 .tx，导致色彩空间错误。

解决方法： 复制并重命名：
wood.jpg → wood_bump.jpg
删除缓存中的旧 .tx，再渲染一次。

预防建议： 始终使用唯一命名：
wood_diffuse.jpg、wood_bump.jpg、wood_roughness.jpg

纹理变黑 / 丢失

问题现象： 材质直接指向 brick.tx，但该文件被删除或移动。Redshift 不会自动回退到 .jpg。
解决方法：
选项 1：将材质路径改回 brick.jpg
选项 2：使用 TextureProcessor 重新生成 .tx

更新了 .jpg 但渲染仍显示旧版本

问题现象： 您编辑了 fabric.jpg，但渲染仍显示旧纹理。
原因： 缓存中仍存在旧的 fabric.tx。Redshift 不会自动检测 .jpg 的更新。
解决方法： 删除缓存目录中的 fabric.tx，再渲染。Redshift 会基于更新后的 .jpg 重新转换。

预转换纹理的色彩空间不正确

问题现象： 您用 TextureProcessor 时 -cs 参数用错了，导致 roughness 发灰或 diffuse 偏暗。
解决方法： 删除错误的 .tx 并重新转换：

颜色贴图（sRGB）：

redshiftTextureProcessor.exe wood_diffuse.jpg -cs "sRGB"

数据贴图（Linear）：

redshiftTextureProcessor.exe wood_roughness.jpg -cs "Linear"
redshiftTextureProcessor.exe wood_bump.jpg -cs "Linear"

规则： 看起来像“照片”的用 sRGB；看起来像“数据/数值”的用 Linear。

D3 - 渲染农场问题

同名纹理在不同目录，导致结果错误

问题现象： 您在两个目录中都有 metal.tx，且转换设置不同。本地没问题，但农场渲染结果异常。
原因： 农场的路径重映射可能加载到错误的 metal.tx。
解决方法： 使用唯一命名：
metal_color.tx、metal_bump.tx、metal_roughness.tx

农场上出现闪烁或纹理损坏

问题现象： 您把 .tx 放在共享网络盘（例如 Z:\Assets\Textures\）。某个渲染节点在 .tx 尚未完全复制或同步完成时就开始渲染，读取到了不完整或损坏的数据，导致逐帧纹理闪烁或材质异常。

解决方法：

小项目的基础人工检查：在提交农场前，进入共享 .tx 目录并：

  • 右键 .tx → 属性（Windows）或 显示简介（macOS）

  • 确认文件大小不为 0 字节

  • 尝试用文本编辑器打开文件：如果能立刻打开且无报错，通常意味着文件未被锁定

大型项目或团队：需要流程层面的协调。
请与渲染农场管理员或技术总监配合，确保在开始渲染前 .tx 已完全同步。多数渲染管理软件可在预检（pre-flight）阶段验证文件同步状态。

D4 - 清理缓存

何时需要清理：

✅ 磁盘空间不足
✅ 因缓存中错误的 .tx 导致渲染异常
✅ 强制 Redshift 基于更新后的 .jpg 重新生成 .tx
✅ GPU 硬件升级后

何时不要清理：

❌ 临近截止日期前（清理后首次渲染会变慢）
❌ 渲染过程中（可能导致崩溃）
❌ 如果缓存目录内混入了您手动保存的 .tx 文件

安全清理步骤：

  • 检查缓存目录内是否存在您手动放入的 .tx 文件（如有请先移出）

  • 关闭 Cinema 4D

  • 删除缓存目录内的所有内容（不要删除文件夹本身）

  • 重启 C4D

  • 首次渲染会更慢（需要重新转换纹理）

缓存目录常见位置：

  • Windows：C:\Users\[YourName]\AppData\Local\Redshift\Cache\

  • macOS：/Users/[username]/Library/Application Support/Redshift/TextureCache/

  • Linux：~/.redshift/cache/

D5 - TextureProcessor 常见错误

色彩空间错误

问题： 用了 -cs "sRGB" 但应为 Linear（或反之）
解决： 删除 .tx 并用正确参数重新转换

文件名不匹配

问题： brick_wall.jpg，但您生成的是 brick_wall_diffuse.tx
解决： .tx 文件名必须与源文件基础名称完全一致：
brick_wall.jpg → brick_wall.tx

将 .tx 保存到缓存目录

问题： 您把 .tx 手动放进了 C:\Users\...\Redshift\Cache\
解决： 立即将其移到项目纹理目录。缓存目录仅用于 Redshift 自动管理。

批量转换时未指定色彩空间

问题： 直接运行了 *.jpg 没加 -cs，导致 bump/roughness 显示不对
解决： 分开转换：

颜色贴图：*_diffuse.jpg -cs "sRGB"
数据贴图：*_roughness.jpg -cs "Linear"

不同扩展名但基础名称相同导致冲突

问题： 同一目录中存在 brick.jpg 与 brick.exr。TextureProcessor 转换后，其中一个纹理会显示错误或缺失。

原因： brick.jpg 与 brick.exr 都会生成 brick.tx。
当两者都被转换时，后者会覆盖前者，Redshift 无法判断 brick.tx 实际对应哪一个源文件。

示例问题：

D:\Textures\
brick_color.jpg → 生成 brick.tx
brick_displacement.exr → 也生成 brick.tx（覆盖前者）

此时材质指向 brick_color.jpg，但 Redshift 找到的 brick.tx 实际来自 brick_displacement.exr，加载结果就会错误。

解决方法： 无论扩展名如何，基础名称都必须唯一：

正确（唯一命名）：

D:\Textures\
brick_color.jpg → 生成 brick_color.tx
brick_displacement.exr → 生成 brick_displacement.tx

错误（名称冲突）：

D:\Textures\
brick.jpg → 生成 brick.tx
brick.exr → 也生成 brick.tx  ❌

D6 - 性能问题

第一次渲染非常慢

问题现象： 第一次渲染启动时间明显过长，有时仅开始渲染前就要等待数分钟。
原因： Redshift 正在后台将所有纹理转换为 .tx。该过程发生在真正开始渲染前的【Preparing Scene】阶段。纹理数量与分辨率越大，耗时越明显。

常见表现：

  • 第一次渲染出现很长的 “Preparing Scene” 阶段

  • 该阶段 CPU 占用明显升高

  • 同一场景第二次及之后渲染启动会快很多

解决方法： 这是自动流程的正常行为。后续渲染会因为 .tx 已生成而明显加速。

若希望完全避免首次等待：
请使用手动流程（B 章节的 Workflow 2），在渲染前用 TextureProcessor 预先转换全部纹理。

这篇文章有帮助吗？

/

评论

0 条评论

请登录写评论。