Unity卡通渲染Shader完全指南：从色带、Ramp贴图到描边高光

在Unity项目里做角色渲染，我经常听到一句话：“想做卡通风格，那就给模型加个描边。”这句话只对了一半。描边确实是卡通渲染最有辨识度的特征，但真正让画面“卡”起来的，是光照和颜色被强制压成了色块。这也就是卡通风格渲染和PBR渲染之间最本质的分歧：一个在模拟真实光线的连续变化，一个在模拟动画师手工上色时那种不加过渡的干脆感。

这篇文章源于我整理Shader笔记时反复验证过的一套流程，覆盖《Unity Shader》第14.1节的核心内容：把漫反射量化成色带、做轮廓描边、让高光也变成硬朗的色块，再补一层边缘光，最后把所有Pass整合进一个可用的卡通材质里。适合正在照着教程写Shader、但总觉得效果“不够卡”的技术美术，也适合打算做风格化项目的Unity开发者。

1. 卡通感的本质：从改光照模型入手，而不是给画面叠滤镜

1.1 真实感渲染的“连续渐变”，恰恰是卡通画面最不该出现的东西

我先说一个经常被误解的点：卡通渲染不是“把饱和度拉高、加个描边”就能做出来的，关键在光照结果从连续值变成离散值。在Unity的Standard Shader甚至URP的Lit Shader里，漫反射光是一个连续变化量，光源方向、法线方向之间的夹角不同，反射能量会平滑衰减。这个衰减在物理上是正确的，但在卡通画面里会带来一种“软乎乎”的体积感。

相反，卡通风格借鉴的是传统赛璐璐动画的上色逻辑。动画里一个球体的受光面通常只有两三层颜色，没有一堆中间过渡色。美术直接画出了“亮部色”“暗部色”两块区域，两块之间是明确的边界。Shader要做的事情，就是模拟这个人工判断的过程，把连续的光照结果按阈值切成若干段。既然是分段，边界就必须足够干净，不能是模糊的半透明过渡。否则看起来仍然是“真实感渲染饱和度调低了”，而不是“这就是个卡通角色”。

所以第一步不是去研究描边，而是重新审视漫反射模型本身。常见做法是把NdotL（法线方向点乘光源方向）的结果拿来做阶梯量化。简单说，当NdotL大于某个阈值，走亮部色；小于阈值，走暗部色。这是整个卡通渲染的起点，几乎所有风格的进阶玩法都从这里延展。

1.2 光照与法线：请不要省略“向量方向统一”这一步

在Shader里做卡通风格，永远要记住一个前提：你需要明确的亮部朝向和暗部朝向，然后在同一个坐标空间里做运算。内置管线的Cg/HLSL里，最常见的是在世界空间计算。先获取世界空间法线，再拿世界空间的光照方向，点积得到的点乘结果就是一个从1到-1的连续标量。

不过很多人在这一步会踩一个坑：直接把dot(normalWS, lightDirWS)的结果用saturate缩到0到1，然后拿去分色带。这样在光源从正面转到背面的过程中，明暗分界线在0附近会显得特别硬，暗部直接掉到全黑。我不建议在写第一个版本时就这样做。可以先用半兰伯特（Half Lambert）把点积范围从[-1,1]映射到[0,1]，让暗部至少保留一些底色的可见性。后续如果美术觉得暗部还不够黑，再在暗部颜色里调整，而不是靠这个映射把整个暗部裁掉。

在做Shader实验室时，我会把光照方向、法线方向用Debug视图输出出来，确认模型在场景里每一个角度的明暗关系都是可控的。很多卡通风格一旦出现不可控黑影，90%不是算法问题，而是把点光源当成平行光用了，或者法线方向在模型空间和世界空间没有正确变换。先把这些数学基础做对，效果才有可能稳定。

2. 漫反射不只一刀切：色带分割、Ramp贴图和暗部节奏

2.1 用Ramp贴图代替大量分支判断，让美术可以“画”光照

上一节说了阈值切割的思路，但真正做角色Shader时，我不建议在代码里堆一堆if和smoothstep来判断三个四五个色带。为什么？因为用代码硬写色带虽然方便，但只要美术想调整暗部偏冷还是偏暖、阴影边界要不要带一点柔和渐变，你就得去改Shader参数，沟通成本极高。

更工程化的做法是使用Ramp贴图，也就是渐变纹理。我们不做复杂的纹理采样，而是把NdotL结果当成这张纹理的UV坐标的横轴。这样场景里的光照方向变化，最终会反映成在Ramp贴图上从左到右的采样位置。贴图最左端是暗部，最右端是亮部。贴图里可以画两段式，也可以画三段式、四段式，甚至可以画成带一点过渡的窄渐变。

以我常用的Cg写法举例：

hlsl复制inline fixed3 ToonDiffuse(fixed3 albedo, fixed3 normalWS, fixed3 lightDirWS)
{
    half ndl = dot(normalWS, lightDirWS);
    // 半兰伯特，把[-1,1]映射到[0,1]，避免暗部完全掉色
    half halfLambert = ndl * 0.5 + 0.5;
    half rampPos = saturate(halfLambert);
    fixed3 ramp = tex2D(_RampTex, float2(rampPos, 0.5)).rgb;
    return albedo * ramp;
}

这里把UV的V方向固定在了0.5，所以Ramp贴图理论上只需要一行有效高度就够了。但美术经常习惯画一横条，我一般建议把贴图做成256x8或者512x16，反正V方向不会影响采样结果。导入Unity后，Wrap Mode设为Clamp，Filter Mode根据需求选择。如果希望阴影边界有一点锯齿过渡，用Bilinear甚至Trilinear；如果希望完全锐利，可以点开材质的生成Mipmap设置后用Point采样。

用Ramp贴图后，明暗分割逻辑被完全移到了贴图里。调光照风格不再需要改Shader，只要打开Photoshop或SP把过渡位置拉一拉、重新导入，角色风格马上能变。这个方法比硬编码阈值要灵活得多，也更容易在不同角色之间复用。

2.2 不依赖贴图的硬切方案：smoothstep与step的实用对比

虽然Ramp贴图很省事，但有一些极端风格只想要简单两段式，或者希望只在Shader内部通过参数控制，不想额外维护贴图资源。这时也可以直接在代码里写。两步式最简单的是step(threshold, ndl)，效果是边界极度锋利，非常像素描漫画。

但直接用step在光照边界处往往会产生锯齿，尤其在边缘位置因为屏幕像素覆盖不连续，会出现比较明显的爬动感。解决方案是给阈值加一个小范围的过渡带，用smoothstep包裹。注意这个过渡带不要开太大，否则又变成柔和光照了。

hlsl复制half shadowBand = smoothstep(_ShadowSmooth, _ShadowSmooth + _Softness, ndl);

参数_Softness我一般控制在0.01到0.05之间。过小会闪，过大会腻。这里有一点要提醒：数值范围和模型实际大小、灯光角度相关，没有“一份通吃”的参数。做项目时最好给美术一个可实时调整的Material面板，让他们在场景里看着角色调。不要试图把光照参数写死在Shader里，美术改起来太痛苦。

2.3 暗部颜色的“节奏”，决定了风格是干净还是脏

很多人第一次写卡通Shader时，暗部直接用黑色，结果角色看起来像烧焦了一样。卡通渲染确实需要干净利落，但不代表阴影只能死黑。实际画面里，暗部颜色的冷暖常常决定了整体氛围，这也是卡通风格区别于单纯“减去光照”的细节。

我的习惯是把环境光、间接光统一合入暗部颜色里。比如室外日景，亮部是暖阳色，暗部可以加一点天空蓝；室内夜景，亮部是冷白，暗部则应该带上灯光的暖色残留。这部分不需要实时计算全局光照，只要把Ramp贴图左端画成微微偏蓝的灰色，右端画成固有色偏白的亮部，就已经能在观感上提供足够的“空气感”。

也可以额外加一个_ShadowColor参数，直接用代码控制暗部着色。常见做法是拿到Ramp采样结果后，再乘一个混合因子，让暗部在原始暗部色和_ShadowColor之间渐变。这样能复用一个Ramp贴图给多个角色使用，只要在Material上把阴影色调成不同冷暖即可。

3. 描边不是滤镜：背面外扩法线的完整实现路径

3.1 理解轮廓线的几何本质

卡通渲染里最显眼的元素就是描边。很多初学者会尝试在屏幕上做边缘检测，也就是后处理描边。但后处理描边最大的问题是：它检测的是像素间的深度和法线突变，很容易受景深、边缘锯齿影响，轮廓粗细也依赖屏幕像素。放在角色和场景交接处还行，纯粹的卡通角色描边还是建议用几何体方式实现。

几何描边的核心思路不复杂：把模型沿着顶点法线方向往外“撑大”一圈。正常情况下，每个顶点只有一个法线方向，沿法线外扩后，模型整体会膨胀出一圈壳。我们把壳的颜色设成轮廓色，壳的正面剔除掉，只让背面成为一圈可见的轮廓。

为什么只保留背面？因为如果壳的所有面都绘制，壳本身就会覆盖原模型，角色会变成一个黑胖子。但剔除正面后，只有外壳外围的边缘和视角偏转处才会暴露出来。外壳正面正好对应模型正面时，被原模型遮挡掉；外壳背面留在轮廓区域，成为描边。这个思路在实践里非常稳定，也是目前游戏角色描边的主流做法。

3.2 一个可落地的描边Pass

下面是我在项目里常用的一个外扩描边Pass。放在主Pass之前渲染，让主Pass在整个流程中负责最终覆盖。

hlsl复制Pass
{
    Name "OUTLINE"
    Cull Front
    ZWrite On

    CGPROGRAM
    #pragma vertex vert
    #pragma fragment frag
    #include "UnityCG.cginc"

    fixed4 _OutlineColor;
    float _OutlineWidth;

    struct appdata
    {
        float4 vertex : POSITION;
        float3 normal : NORMAL;
    };

    struct v2f
    {
        float4 pos : SV_POSITION;
    };

    v2f vert(appdata v)
    {
        v2f o;
        float4 clipPos = UnityObjectToClipPos(v.vertex);
        float3 viewNormal = mul((float3x3)UNITY_MATRIX_IT_MV, v.normal);
        float2 offset = TransformViewToProjection(viewNormal.xy);
        clipPos.xy += normalize(offset) * _OutlineWidth * clipPos.w;
        o.pos = clipPos;
        return o;
    }

    fixed4 frag(v2f i) : SV_Target
    {
        return _OutlineColor;
    }
    ENDCG
}

这段代码做的事情很简单，但有几个细节很重要。第一，描边宽度乘了clipPos.w，这是为了让轮廓在屏幕上保持相对稳定的像素宽度。如果少了这一步，同一描边宽度值在近处和远处会完全不同，角色走远后描边会看不出粗细变化。第二，法线要转到视图空间做投影，否则使用带旋转或缩放的模型时，描边方向容易歪掉。代码里用了UNITY_MATRIX_IT_MV逆转置矩阵变换法线，这是处理非均匀缩放的标准做法。

实际操作中，_OutlineWidth并不是一个对任何模型都通用的绝对值。同样是0.01的数值，在1米高的角色身上可能刚好，在10米高的角色上就会描边粗得夸张。建议在Material面板提供描边宽度参数，并在项目里针对角色统一尺寸或调一套默认值。

3.3 描边最常见的坑：法线不连续导致的“轮廓断裂”

当我第一次把外扩描边套到角色模型上，经常遇到一个问题：角色脸部边缘出现一块一块的三角形破边，轮廓线在眼角和嘴角处断成了好几截，而不是一条干净闭合的线。原因不是Shader写错，而是模型的法线并不是统一平滑的。

美术建模时，为了做出硬边和自然的转折，会把一些面的法线“断开”。比如一个长方体，如果每个面法线都平滑过渡，显示效果会变成圆角。为了棱角清晰，建模软件里会把法线设置成不连续，导致同一个位置的顶点实际上有多个不同法线。外扩描边沿这些不连续法线向外撑后，原本应该连在一起的轮廓就被撕开了。

解决方式不是让美术把法线全部平滑掉，那会毁掉模型的硬表面效果。常见做法是为描边单独准备一套“平滑法线”数据。在Unity里可以写一个编辑器脚本，遍历模型所有顶点，将位置相同的顶点法线做平均计算，然后把平均后的法线写回模型的新UV通道或额外顶点数据中。描边Shader采样这个平滑法线，主Pass仍用原始法线，两者互不干扰。

如果项目不想额外改模型，也有一个妥协方案：把法线外扩改成“屏幕空间法线检测”或其他后处理方式，但效果稳定性会差一些。做角色卡通渲染，我强烈建议在资产流程里就为描边准备好平滑法线，这一步解决的是最底层的问题，比调几百个参数都更有价值。

3.4 描边宽度和画面风格如何取舍

描边不是越宽越好。以日式赛璐璐风角色为例，描边宽度通常在角色整个画面高度的0.5%到1%左右，太粗会让角色看起来像儿童简笔画，太细则容易在远景或移动时闪烁消失。

我习惯在描边Pass之外再做一个顶点色通道的控制：把模型顶点色里的R通道作为描边权重，模型在衣服边缘需要更细的描边，就在顶点色里填一个较小的值；头发或轮廓需要强调的区域填较大值。Shader里把_OutlineWidth乘上顶点色的R通道，就实现了局部描边宽度控制。这个方法比全局统一宽度要精致得多，也是商业项目里的常见做法。美术在DCC软件里花一点时间刷顶点色，效果提升非常明显。

4. 高光也被“驯化”了：卡通高光是用阈值切出来的

4.1 传统Blinn-Phong高光先做幂运算，再做阈值化

卡通渲染里，高光的处理和漫反射如出一辙：真实感高光需要柔和衰减，卡通高光则要把衰减压成硬边界。用标准的Blinn-Phong模型时，我们会计算法线方向和半角向量的点积，再通过pow控制高光的集中程度。这个pow的结果在0到1之间，是一个光滑的弧形衰减。

对真实材质来说，这个弧形衰减就是皮肤、塑料、金属等质感的关键。但卡通赛璐璐画面中，高光通常是“贴”在物体表面的亮色块。比如动漫角色的头发上经常有一大块白色高光，亮度与周围颜色差异大，边界分明。这种高光不能用pow的原始值来绘制，需要对结果再做一次阈值化，让大于阈值的部分输出一个固定高光色，小于阈值的部分直接归零。

hlsl复制half nh = saturate(dot(normalWS, halfDirWS));
half spec = pow(nh, _Gloss);
half toonSpec = smoothstep(_SpecThreshold, _SpecThreshold + _SpecSmooth, spec);
col.rgb += toonSpec * _SpecColor * lightColor.rgb;

_Gloss负责决定高光的锐利程度，值越大，高光范围越小、越亮。_SpecThreshold负责决定“多亮才算是高光”，阈值越高，高光色块的面积越少。两个参数配合使用时，很容易调出漂亮的两段或三段高光效果。_SpecSmooth的存在是为了防止高光边界锯齿，一般不需要给太大。

需要留意的是，Blinn-Phong的高光形状是圆的，而且会跟着视角移动改变位置。如果你观察一个球体，这个算法能提供合理的高光。但游戏角色的头发高光往往不是物理规律的结果，而是美术刻意设计的造型。漫画风的头发高光通常是几个明确形状的大块，这已经超出Blinn-Phong能表达的范围。这种情况下，更合适的方案是放弃动态高光，直接在高光贴图里画出形状，再通过视角方向或光照方向做简单的显隐控制。

4.2 多光源场景下的高光稳定性问题

实际游戏场景里不会只有一个平行光。屋顶可能有暖色点光源，地面有冷色补光。如果卡通Shader对每个光源都跑一遍阈值高光，画面上的高光点会变得又多又乱，完全失去风格化设计的秩序感。这也是“卡通感觉崩了”的高频原因。

我的习惯是：在主要角色的卡通材质上，主平行光负责漫反射色带和主高光，附加点光源只负责轻微改变明暗，不再贡献高光。可以在Shader里写一个_ReceiveAdditionalLightSpecular开关，默认关闭。项目需要灯光互动的地方，再单独打开并进行亮度阈值控制。这样能保障角色在主灯光下有稳定的阴影分割，不会因为在场景里转个身就突然多出一堆奇怪高光。

如果你要调试高光，请在场景里放置一个纯灰色环境球，然后把主光源的强度和角度固定下来。不要边拖灯光边调高光参数，否则你会永远找不到最优解。先固定外部条件，再在材质参数上收敛。

5. 边缘光不是描边，它是给色块“加呼吸感”的关键

5.1 菲涅尔边缘光的计算与参数

卡通渲染角色如果只是一层色块加描边，在深色背景里往往会贴在一起，缺乏空间感。这时边缘光能帮上大忙。边缘光和描边很容易混淆，但在视觉上完全不同。描边是几何体最外圈的黑色线框，用来固定轮廓；边缘光则是物体靠近视角边缘处出现的亮色，模拟光线在薄边缘透出或被反射的效果。

标准做法是算菲涅尔项：视线方向和法线方向的夹角越小，越靠近边缘，越应该出现边缘光。这里的核心公式是pow(1 - dot(N, V), power)。

hlsl复制half fresnel = pow(1.0 - saturate(dot(normalWS, viewDirWS)), _RimPower);
half rimIntensity = smoothstep(_RimThreshold, _RimThreshold + _RimSoftness, fresnel);
col.rgb += _RimColor.rgb * rimIntensity * _RimColor.a;

_RimPower决定了边缘光的衰减速度。数值越低，光从边缘向中心蔓延越多；数值越高，光越集中在最外圈。如果你想做一个非常锐利的二次元描边感，可以把_RimPower拉高，再配合smoothstep裁掉柔和的过渡。如果希望有一点空气感，使用较低的_RimPower，让光在边缘两侧形成一层均匀的包围。

需要特别注意颜色的选择。暖色边缘光适合夕阳、逆光氛围，冷色边缘光适合夜晚、战斗场面。边缘光不是越亮越好，我经常在角色侧后方补一盏很弱的蓝色边缘光，让角色和背景分开，同时不会让人注意到这其实是Shader在“作弊”。

5.2 边缘光与描边、阴影之间的关系

这三者经常互相干扰。描边在模型最外部，边缘光紧贴着描边内侧，阴影色带通常在中间区域。如果角色脸色受到一个很强的边缘光，视觉上会把脸部和头发轮廓撑得很亮，脸部中央却是一大块暗色，导致五官显得脏乱。

因此边缘光不应该在同一层和所有物体“一视同仁”。我通常会留一个控制因子：单独对头发、脸部、身体材质使用不同边缘光强度。脸部动画角色尤其要控制得轻一点，因为人脸是最需要观感舒适的地方。如果面部边缘光太强，角色从侧面看会像一个发光灯泡，原有的五官立体感全被破坏。

调试时如果要精确看到边缘光区域，可以把Shader临时改到输出rimIntensity单通道，Fresnel项会变成一张黑白遮罩图。这样你能直接判断光带范围是否卡在角色轮廓内侧。调完后再恢复为完整颜色。这个方法对任何新写的光照项都适用，能大幅缩小排查范围。

5.3 环境光与最终氛围的组合技巧

到这里，漫反射色带、描边、高光、边缘光都有了，最后还需要一层环境光作为暗部补充。真实渲染中的环境光来自天空盒和反射探针，卡通渲染中则往往用一个纯色或低饱和度的渐变代替。

我通常会在Shader里暴露一个_AmbientColor参数，把环境光从暗部颜色中分开。这样在同一个光照环境里，想单独调一个角色的暗部氛围时，不需要改Ramp贴图，只需要调节这个环境色。比如傍晚场景，可以给模型暗部加入微弱的紫红色；在室内，则调配成偏黄的灯光底色。

要注意的是，环境光不要给得太猛。如果环境光过亮，角色暗部会出现“灰起来”的现象，漫画感严重下降。控制在固有色暗部以下，让它只是让阴影不再死黑，半透明层次依然靠Ramp贴图来主导。

6. 从能渲一张图到能放进项目：管线、性能与实测心得

6.1 URP与内置管线的差异，直接决定Shader怎么写

如果你现在打开Unity Hub创建的是URP工程，很多内置管线的Shader代码不能直接跑通。内置管线的UnityObjectToClipPos、_LightColor0这些宏在URP里虽然部分兼容，但光照函数、阴影采样结构完全不同。我自己在URP里做卡通渲染时，会写一个全新的HLSL版本，尽量不依赖内置光照宏。

URP中获取主光的方式已经从原来的_LightColor0变成了GetMainLight()。漫反射、阴影、高光等参数都要通过Light结构体获得。而描边Pass的顶点变换比较简单，在URP里仍然可以用TransformObjectToHClip完成。如果你是一边看旧教程一边在URP里做，很容易陷入“能编译但画面光感不对”的状态。建议直接检查自己工程里有没有GetMainLight相关代码，没有的话就要把Shader按URP模式重写了。

如果你还在用内置管线开发且项目没有迁移计划，不建议强行套URP的代码。因为功能上老代码稳定可用，踩坑也少。如果项目新建且面向移动端，直接用URP，然后把核心光照从兼容代码中抽出来，重构成统一结构。卡通风格Shader的框架并不复杂，真正花时间的是把管线差异对接好。

6.2 移动端性能预算与实机表现

卡通Shader的性能消耗比PBR小很多，因为它不需要那么多高光计算和复杂微表面模型。但这并不代表可以随便写。最容易超预算的点有两个：描边Pass和采样数量。

每个使用描边的角色都会多一个绘制Pass，相当于角色的渲染线程负载翻倍。如果屏幕上有几十个角色，描边Pass的数量会很可观。一定不要把描边Pass挂在所有透明和半透明物体上，只给真正需要的角色和道具开描边。半透物体如果用描边Pass，还要额外处理穿透问题，消耗更高，非必要不启用。

Ramp贴图可以使用64x16，甚至32x8。因为它的横轴只是NDotL的一段亮度映射，不需要很高的分辨率。把Ramp设成2048x2048是一种纯粹浪费且降低缓存命中率的做法。最后在Mobile模式下建议把Shader里大部分fixed/half精度变量使用半精度，减少移动GPU ALU压力，对发热控制也有帮助。

6.3 实测高频问题与排查表

每次做卡通Shader，我总会遇到类似问题。总结成表，能帮大家快速定位。

我还想特别提一个颜色空间问题。如果项目使用了Linear色彩空间，Ramp贴图的导入设置会直接影响最终明暗。建议把这张贴图的sRGB选项根据效果开关都测试一遍。不要想当然认为贴图都是sRGB，用于颜色映射的Ramp如果走错色彩空间，暗部色会看起来完全不一样。调试时用一个大色块场景逐一对照，而不是直接在角色脸上猜测。

6.4 真正让卡通风格活过来的最后一步

全套技术做完之后，画面可能依然不够“活”。这时候最常见的补强手段已经不在Shader里，而在灯光和动画状态。卡通渲染对主光源方向极其敏感，因为色带边界本质上就是在灯光方向和模型表面法线相对固定的情况下产生的。如果灯光在场景里旋转，角色会像换了一套光照性格。为了保证演出效果，项目通常要为角色打固定角度或跟随摄像机的主光，或者在不同剧情场景切换预设灯光角度。

另外一点是角色动作。色带锐利的卡通风格很“挑动作”，当角色侧对光源时，阴影边界刚好落在鼻梁或锁骨上，会非常出效果；当角色正对或背对光源时，阴影区整体覆盖，会显得单调。做战斗动画的人如果理解这一点，会在关键帧故意让角色稍微侧身，让暗部区域划过面部或手臂来提升张力。

这些经验不太容易写进代码，但却是卡通渲染项目落地时非常重要的艺术决策。技术只是提供了控制方式，真正好的卡通画面，是技术和审美互相校准的结果。我自己做完这套14.1卡通风格流程后最大的体会是：Shader代码反而是最简单的部分，把色带、描边、高光、边缘光梳理成能由美术自由调控的参数，才是这个风格能不能在项目里长期稳定活下去的关键。