企业官网建设流程全解析

是不是很眼熟：SP里调得好好的BaseColor，贴进Maya，挂上Arnold渲一帧，整体灰了一层，饱和度也缩了水；换到RedShift渲，颜色又是另一个味道。如果你也卡在Maya和SP的贴图颜色对不上这道坎上，那么这篇关于Maya ACES工作流程配置的内容，应该正好是你需要的。这篇文章会顺着贴图从Substance Painter导出、进入Maya连接材质、交给Arnold或RedShift渲染，再到最后用Photoshop还原ACES渲染图的完整链路，把色彩空间这条“隐藏技术债”拆开说清楚。适合做资产贴图、灯光、渲染合成方向的朋友参考，尤其是刚接触ACES但被各种灰蒙蒙、饱和度异常搞得头大的人。

1. 为什么SP里调好的贴图一进Maya渲染就变味

1.1 先对号入座：这些症状是不是全踩过

我最早遇到这个问题的时候，第一反应是SP导出设置不对，第二反应是Arnold的Gamma没调，折腾了一整天，最后发现锅根本不在渲染器，而在色彩空间。

常见的症状大概有下面几类：

• BaseColor在SP里看是正常的红砖色，到了Maya渲染出来整体发灰发粉，像蒙了一层雾。
• 暗部尤其明显，黑的地方不够黑，甚至带一点诡异的绿边或紫边。
• 同一个材质，Arnold和RedShift渲染出来的观感差异很大，一个偏暖一个偏冷。
• Metalness和Roughness贴图一旦接上去，金属高光就“假”得离谱，要么过亮要么失去层次。

如果你也遇到其中两三条，基本可以锁定是贴图从SP到渲染器之间的色彩空间没有统一。

1.2 说人话版本的色彩空间原理：解冻再下锅

要理解这个问题，得先弄清楚一个概念：渲染器内部做光照计算时，要求所有贴图里的数值都是线性的，也就是“原始亮度数据”。而我们在显示器上看到的一切图片，包括SP里导出的BaseColor，通常都经过了sRGB的伽马编码，也就是亮度被“压缩”过一遍。

sRGB是给显示器用的编码方式，好处是用8bit就能存下更细腻的暗部层次。但渲染器不认这套，它需要的是linear数据，也就是解掉伽马之后的原始数值。你如果在Maya里把一张sRGB贴图当成linear数据直接用，等于素材没“解冻”就下锅了，出来的颜色一定会偏亮、偏灰。

这也是为什么同样的贴图，在SP里看正常，到了Maya里就不是那个味道。因为SP的视口会自动叠加sRGB显示补偿，而Maya里贴图的Color Space标记错了的话，渲染器不会帮你做这个补偿，数值就会被重复处理或者完全不处理。

2. ACES到底做了什么：一次色彩空间的“大一统”

2.1 ACES不是滤镜，是电影行业推的工业标准

ACES全称是Academy Color Encoding System，电影行业推的一套标准化色彩管理体系，现在CG行业越来越多的项目都在往这个方向迁。它的价值一句话总结就是：让拍摄素材、CG渲染、后期合成、影院放映都在同一个色彩空间语境下工作。

以前每个软件各管各的，Maya里看到一种颜色，Nuke里又是另一种，Photoshop里再打开又变一个样，所有环节都靠人工去“找补”。ACES用一套统一的工作空间和输入输出变换，把这件事标准化了。

2.2 IDT、RRT、ODT，以及ACEScg和ACES2065-1

ACES体系里你会反复遇到几个缩写，不需要背得多熟，但得知道它们各管哪一段：

• IDT（Input Device Transform）：把不同来源的输入色彩空间转到ACES工作空间，比如sRGB贴图进ACES就靠这一步。
• RRT（Reference Rendering Transform）：做“参考渲染”，决定最终画面从线性数据变成观感良好的影像时的影调映射方式。
• ODT（Output Display Transform）：针对不同显示设备做的输出转换，比如转成sRGB显示器用的颜色。

在实际项目里，你主要接触的是ACEScg，这是CG渲染专用的工作空间，色域比sRGB大不少。ACES2065-1则更多是存档和交换用的空间，平时不会直接拿来算图。Maya、Arnold、RedShift里说的“用ACES”，基本就是指以ACEScg作为工作空间，渲染完成后做一个ACES的ODT变换输出到显示器或成片。

2.3 好处明显，代价也不小

ACES带来的最直观好处是：不同DCC之间颜色终于能对上了，高光的衰减更自然，暗部不容易出现那种硬邦邦的断层，后期调色空间也更大。但它不是免费的——一旦切到ACES，你会发现之前熟悉的贴图观感全变了，之前对着sRGB调出来的灯光强度也不合适了，如果不整条链路都按ACES走，反而会越搞越乱。

3. Maya这边怎么切换：Color Management与OCIO配置实操

3.1 在Maya里开启ACES工作空间

这里以Maya 2022以后版本为例，路径基本一致：打开Window > Settings/Preferences > Color Management，把Enable Color Management勾上。关键是下面的Working Space，默认是sRGB或者scene-linear，要改成ACEScg。Output Transform一般选sRGB / Rec.709对应的选项，也就是说工作空间用ACEScg算，最终显示到普通显示器时仍然用sRGB曲线输出。

需要提醒的是，Maya这么做的基础是它内置了OpenColorIO（OCIO）色彩管理框架。如果你的项目里有自己的OCIO配置，也可以在Color Management的Settings里指定OCIO config文件。团队项目里OCIO配置必须统一，否则一个人用官方ACES 1.2配置、一个人用项目自定义配置，贴图和灯光颜色全都会互相漂移。

3.2 文件节点的Color Space标记才是大头

全局设置打开之后，重头戏落在每个File节点的Color Space属性上。这个属性决定了一张纹理进入Maya之后，系统要不要对它做色彩空间转换。

对于SP导出的BaseColor这类颜色贴图，要在File节点的Color Space里选sRGB。对于Roughness、Metallic、Normal、Height这类数值贴图，一定要选raw，也就是不做任何色彩空间转换，让数值原样进渲染器。这项设置特别容易被忽略，但从我经验看，项目里百分之六七十的“渲染偏灰”“颜色发闷”，最后查下来都是这里标错了。

3.3 一个快速验证的方法：渲染结果和SP对一下

配置完心里没底的话，可以做一个很简单的验证：场景里放一盏方向光和一个标准球，材质只接BaseColor贴图，用Maya渲染一张，再用SP的标准光照环境渲染一张同一张贴图，对比两者的颜色倾向。如果整体色温、明暗关系基本一致，说明链路通了。如果明显偏灰或者偏亮，不要急着调灯光，先回到File节点的Color Space去检查。

我自己做这个测试的时候，还习惯在Maya的Viewport里把显示变换切到与最终输出一致的模式，因为很多时候渲染结果没问题，是视口预览的显示变换没跟输出统一，导致你以为渲染错了。

4. Arnold和RedShift的接入差异，以及最容易忽略的Viewport预览

4.1 Arnold：先看它有没有吃Maya的全局设置

Arnold在Maya里通常是走Maya的Color Management。也就是说Maya的Working Space设成ACEScg之后，Arnold渲染时也基于ACEScg做光照计算。MtoA的Render Settings里其实也有Color Management相关选项，比如可以单独启用ACES输出，但我建议默认先跟随Maya，不要两边各设一套，不然排查起来太痛苦。

Arnold渲染输出的格式也要提前想好。如果只输出sRGB的8bit PNG，那在渲染器内部做完ODT之后，高光和色域信息都已经被压缩固定了。如果你打算后期再进Nuke或者Photoshop精调，最好输出EXR，而且EXR里颜色信息要保证是ACEScg的，这样后期才有完整的色彩空间给你操作。

4.2 RedShift：在Render Settings里找Color Management

RedShift和Arnold的逻辑相似但入口不同。你需要打开RedShift Render Settings，在Color Management卷展栏里选择与ACES相关的选项，比如ACES或OCIO。选定之后RedShift会以ACEScg作为工作空间，并用对应的色调映射显示到视口和IPR。

这里有一个很容易踩的坑：RedShift的IPR最终观感受Tone Mapping影响很大。同样是ACES工作空间，你选ACES的SDR Video输出和直接输出sRGB，看到的明暗、饱和度都有差别。所以项目里要约定好，IPR预览时用和最终成片一致的显示变换，不然你对着IPR调了半天的灯光颜色，换到成片通道又不对了。

4.3 视口显示和最终输出的“色差陷阱”

说实话，很多“Maya里颜色不对”的第一现场都在视口。Maya的Viewport默认有自己的显示变换，按数字键7进入高质量着色以后，显示结果和Arnold/RedShift的最终输出未必一致。

建议在开始渲染之前，先把Maya的Color Management输出变换和最终显示器色彩空间统一，再把渲染器的IPR显示统一到同一套ACES输出变换上。让Viewport、IPR、最终成片三者看到的画面一致，后面才不会做无用功。

5. SP导出贴图时，哪些通道标sRGB、哪些标Raw

5.1 SP内部显示和导出的区别

Substance Painter在视口里看到的是经过sRGB显示补偿后的结果，但导出贴图时会按你指定的色彩空间去写文件。大部分人默认导出后拿到的BaseColor是一张sRGB编码的图片，而Roughness、Metalness、Normal这类贴图是raw/linear数据。

问题往往出在“我以为SP导出的都是sRGB”或者“我全都设成了raw”。如果Roughness这种数值贴图被标成了sRGB，相当于给它加了一道伽马曲线，原本0.5的粗糙度数值会被重新映射，材质表面的高光分布立刻走样。金属度和法线贴图被标sRGB后问题更严重，法线方向会被计算错，高光会在模型表面乱跑。

5.2 逐通道配置建议

下面是我在SP导出配置里常用的色彩空间约定，基本覆盖PBR Metal/Roughness流程：

这个表几乎是我每次建立项目时都会发给团队同事的。别看它简单，很多材质表现不干净、金属边缘脏乱差，查到最后都是Metallic或者Normal的颜色空间没设对。

5.3 导出习惯：命名即规范

我习惯在SP导出时就给贴图打上明确后缀，比如T_Rock_BaseColor、T_Rock_Roughness、T_Rock_NormalTanget。这样后续在Maya里连节点的时候，一眼就能判断这个文件该用什么Color Space。凡是出现BaseColor、Diffuse、Albedo字样的，就标sRGB；凡是Roughness、Metallic、Normal、Height、AO这些字样的，闭眼标raw。

颜色贴图如果想在ACES流程下更接近原始SP观感，有些团队会手动把BaseColor的饱和度在SP里提前拉高一些，因为在较宽色域的工作空间下，同样的sRGB数值看起来会比传统流程“淡”一点。但这个属于风格取舍，不建议新手一上来就做，先把色彩空间链路搞对再谈风格微调。

6. Arnold/RedShift渲染输出后，PS里怎么正确还原ACES结果图

6.1 为什么ACES渲染图在PS里看得灰灰的

这是大家问得最多的问题之一：渲染出来的EXR在Nuke里正常，放进Photoshop以后整个画面又灰又平，像丢了对比度。

原因很直接：PS不会自动帮你做ACES的RRT/ODT转换。它看到的是一份ACEScg空间下的线性数据，如果直接当普通sRGB图打开，画面必然发灰、发闷。这不代表渲染错了，也不代表PS坏了，只是缺乏一次“显示变换”。

6.2 正路是先转换色彩空间，再进PS修图

我项目里最稳妥的做法是：渲染输出EXR之后，先不直接进PS，而是在支持OCIO的应用里完成ACES到sRGB的显示变换，生成一张sRGB的PNG/TIFF，再交给PS做最终润色。这里常用的软件包括Nuke、DaVinci Resolve、Krita，甚至一些纯命令行工具也能批量完成EXR到sRGB的转换。

如果你手里的工具链只有PS，有两个办法：

• 在PS里安装基于OpenColorIO的插件，让PS能够识别并转换ACES色彩空间。
• 在渲染器里设置输出时直接生成两版：一份ACEScg的EXR用于归档和原数据保留，一份sRGB的8bit/16bit PNG用于直接进入PS出图。

我是强烈建议用第二种办法的。它省去了后期反复转换的麻烦，而且成片链路里始终有一份“原始底片”留存，出问题还能回头重新校。

6.3 实在只能用PS手工还原，步子别迈太大

如果当下没有Nuke也没有OCIO插件，只能用PS硬还原ACES渲染图，那我的建议是：只做轻量调整，不要硬拉曲线。

把PS的Color Settings里的RGB工作空间设成sRGB IEC61966-2.1，打开渲染输出后，先不要做局部调色，先用曝光、色阶、曲线把整体对比度找回一个大概。ACES转sRGB之后，通常需要轻微提升对比度、适当降低高光、找回暗部细节。饱和度这块尤其要克制，因为硬拉饱和度很容易把肤色和金属色搞假。

手工还原只能是临时策略。它最大的问题不是效果差，而是不可复现——今天你凭感觉调成这样，明天换一个人调，出来完全是另一个风格，根本无法用于多人协作和跨期交付。

6.4 我在项目里常用的输出管线

分享一条我目前实际在用的管线，基本可以稳定保证从SP到PS的颜色大体一致：SP导出贴图后，在Maya中连接File节点并严格标好色彩空间；Arnold或RedShift以ACEScg工作空间渲染，输出EXR主通道，同时渲染器内指定sRGB的显示变换输出一份预览用PNG；进入Nuke用OCIO把EXR转成sRGB TIFF；最后进Photoshop做精修和排版输出。这条链路里每一步的颜色空间都是显式指定的，不会出现“哪个环节偷偷改变颜色”的情况。

7. 一张自查表：从贴图到出图，色彩空间常见的症状和解法

7.1 案例一：整个画面灰蒙蒙，暗部发闷

原因大概率是线性数据被当成sRGB输出，或者渲染结果没做ODT转换。检查Maya的输出变换是不是对应sRGB/Rec.709，检查File节点的BaseColor贴图是不是标了raw导致没有伽马还原。处理方式是先在节点层面修正，再去看渲染器输出变换。

7.2 案例二：颜色饱和度“假高”，像玩具塑料

这个经常出现在传统sRGB流程切换到ACES之后。原因是灯光强度、贴图值和显示变换还沿用旧习惯，导致ACES宽色域里高饱和度被放大。处理方式是回到渲染器里把曝光和色调映射重调，不要在一张成片上反复拉饱和度。

7.3 案例三：金属高光奇怪，粗糙度变化生硬

优先查Metallic和Roughness的File节点是不是被标成了sRGB。这两个通道必须是raw。如果是，即使渲染器再强，金属结果也会发飘、发假。Normal贴图如果标了sRGB还会让高光方向错乱，检查时一定看到Normal通道也要确保是raw。

7.4 色彩空间自查清单

这张表我一直贴在工作台边上。每次有人报我“颜色不对”，我不会先怀疑引擎，先按这张表过一遍。绝大多数时候，问题都能在表格前四行找到。

8. 我个人的实操习惯：对ACES保持“选择但克制”的态度

8.1 不是所有项目一上来就值得全切ACES

我要说句实在话：ACES是好东西，但它不是万能的。如果项目交付目标就是sRGB的电商图、产品渲染这类单张静帧，而且团队里没有后期合成环节，那全面切ACES反而会增加沟通和调试成本。这种情况下，只要保证Maya内部线性工作流正确、SP贴图色彩空间标记无误，用传统的sRGB输出也能得到很好的结果。ACES真正发力的地方是多软件协作、需要大动态范围、要进Nuke做后期合成、或者摄影和CG素材混合的片子。技术选型永远为交付服务，别为了炫技把全组拖下水。

8.2 SP的视图预览先切到ACES模拟

有一个小技巧我很早就开始用了：在Substance Painter里，如果软件版本支持在Viewport的色彩管理预览中切换ACES和sRGB，那么建模的时候直接切到ACES预览工作。这样在SP里看到的效果就提前靠近Maya里Arnold或RedShift最终渲染的调子，而不是回到Maya里再被“惊喜”一次。这个习惯帮我省掉了无数次来回返工。当然，前提是你已经确定项目会用ACES作为工作空间。

8.3 团队协作时把约定写清楚

最后想说的是，ACES流程实施起来技术门槛并不高，高的是团队里每个人对同一套标准的理解。我们项目里会把色彩空间约定直接写进资产制作规范里：所有BaseColor切片标sRGB，所有数据贴图标raw；所有Maya工作空间统一ACEScg；所有最终渲染输出统一走OCIO到sRGB；所有进入PS的图必须先完成显示变换。这些规则看起来简单，但坚持执行半年以后，你会发现贴图在SP里长什么样，渲染出来就长什么样，PS里继续调色也不会跑偏。这才是ACES流程带来的最大红利：不是单一软件里的某个按钮，而是整条流水线终于能在一个统一且可复现的色彩语境下工作了。