view space Z也就是 camera forward 方向的深度而不是length(viewPos)这在大 FOV 或斜角观察时会导致 rim 厚度变化。“边缘判定的度量空间”变了。之前你的逻辑大致是采中心点rawDepth采左/右/上/下rawDepthLeft/Right/Up/Down做差当前像素和四邻域在硬件深度缓冲值上差多少。”这个量的问题是它在透视投影下是非线性的。近处一点点实际距离变化映射到 zbuffer 里可能很大远处很大实际距离变化映射到 zbuffer 里可能很小。原来你测的是“depth buffer 数值跳没跳”。现在你测的是“相机前向距离跳没跳”。这两者在工程语义上差很多。rawDepthDelta是 GPU 深度缓冲里的差值。它更接近“投影后 z 曲线上的变化量”。linearDepthDelta是线性视空间 Z 差值。它更接近“这个像素和邻居离相机前后差了多少米”。当然严格说不一定是“米”取决于你场景单位但语义上就是视空间距离差。depth discontinuity 的空间频率half-resolution buffer 做 edge detection然后再 upsampleGPU cache localitydepth discontinuity frequency在 URP 里_CameraDepthTexture 的分辨率通常不是你单独给它设一个自定义值而是主要受这些因素控制Render Scale最直接。URP Asset 里的 Render Scale 会影响相机渲染目标分辨率depth texture 通常跟着变。相机输出分辨率 / Game 视图分辨率屏幕越大depth texture 通常也越大。动态分辨率 / Upscaling开了动态分辨率或上采样depth 的实际尺寸也可能跟着变化。Renderer 实现细节某些平台/路径下 depth 可能和 color target 同尺寸某些情况下会有内部差异但一般你不单独手工指定。所以结论是可以间接调通常不是“给 _CameraDepthTexture 单独设宽高”最常用手段是调 URP Render Scale如果你的目的不是性能而是让深度边缘更稳定优先级通常是先用 linearDepthDelta再做距离补偿最后才考虑靠提高 depth 分辨率救边缘因为分辨率提升只能缓解采样粗糙不能解决算法本身的距离敏感性。改采样半径能改变对邻域深度变化的敏感范围不能改变远处物体只有很少屏幕像素时的信息缺失不能仅凭这个Named Attribute节点就断定模型一定存在顶点色。它只是“按名称读取属性”。如果属性不存在Exists会是 false并且输出会是默认值。你这个节点配置为Type:ColorName:Color含义是在几何属性里读取一个名为Color的 attribute通常就是顶点色。但注意两点Blender attribute 可以在Vertex / Face Corner / Point / Instancedomain 上如果不存在输出就是默认值(0,0,0,1)取决于上下游所以仅有这个节点 ≠ 一定存在 vertex colorBlender 里的顶点属性要先被导出成 Unity 认识的东西shader 才能用。常见可用通道是POSITIONNORMALTANGENTCOLORTEXCOORD0~7有时还能借 blend weights / indices但不建议乱用所以实际流程是在 Blender 里把命名属性写入可导出的通道导出 FBX/glTFUnity 导入后这些数据变成 vertex color、uv2、uv3 之类shader 里从对应语义读取最常用的映射方式如果 Blender 属性是一个标量 mask推荐写到 Color.r或 UV2.x如果 Blender 属性是一个向量方向推荐写到 Color.rgb或 UV2.xyz / UV3.xyz如果要高精度优先 UVUnity shader 里怎么读如果你把 Blender 属性烘焙到了顶点色struct Attributes { float4 vertex : POSITION; float3 normal : NORMAL; float4 color : COLOR; float2 uv : TEXCOORD0; };然后在顶点/片元里直接用float mask v.color.r; float3 dir v.color.rgb * 2.0 - 1.0;如果你把 Blender 属性烘焙到了 UV2struct Attributes { float4 vertex : POSITION; float3 normal : NORMAL; float2 uv : TEXCOORD0; float4 uv2 : TEXCOORD1; };读取float mask v.uv2.x; float3 dir float3(v.uv2.xy, 0.0);如果是 UV3float4 uv3 : TEXCOORD2;对应你这个 Blender 节点推荐这样映射从你前面的信息看节点里至少有ColorUV0smoothnormalWS建议映射为Color - Unity COLORUV0 - Unity TEXCOORD0smoothnormalWS - Unity TEXCOORD1 或 TEXCOORD2这样 shader 里可以写成struct AttributesOutline { float4 vertex : POSITION; float3 normal : NORMAL; float4 color : COLOR; float2 uv0 : TEXCOORD0; float3 smoothNormal : TEXCOORD1; };然后float maskFromColor v.color.r; float3 outlineDirOS normalize(v.smoothNormal); float maskFromTex SAMPLE_TEXTURE2D_LOD(_OutlineMaskTex, sampler_OutlineMaskTex, v.uv0, 0).r;最关键的限制如果你只是“在 Blender 里新建了一个 Named Attribute”但没有把它烘焙进导出格式支持的顶点通道Unity 里是读不到的。也就是说这种写法在 Unity 里不存在ReadNamedAttribute(smoothnormalWS)Unity 没这个能力。它只认网格顶点缓冲里已经存在的流。如何判断导入后有没有带进来你可以在 Unity 里做最简单测试把属性先写进 vertex colorshader 输出 color.rgb如果模型显示出预期分布说明导入成功例如片元里临时写return float4(i.color.rgb, 1.0);如果全黑说明导出没带Unity 导入没保留或你读错通道了对你当前项目最实用的建议如果是要复刻 Blender 那套 outlinemask 类属性写进 vertex colordirection 类属性写进 uv2/uv3UV0 继续走原始纹理坐标shader 里不要依赖“属性名”只依赖语义通道如果你要我下一步可以直接告诉你 Blender 里怎么把 smoothnormalWS 烘焙到可导出通道然后把 LaevatSkin.shader 改成实际读取 COLOR 和 TEXCOORD1 的 outline pass从几个实际工程角度说明为什么常说“VS 不适合采样贴图”。1. VS 没有像素导数ddx / ddy像素着色器在纹理采样时依赖屏幕空间导数来确定 MIP LevelLOD ≈ log2(max(|ddx|, |ddy|))VS 中没有ddx/ddy因此Texture.Sample()在 VS 中通常会退化为LOD0或 driver heuristic。如果纹理很大会导致明显的 aliasing 或 cache miss。因此 VS 采样一般需要Texture.SampleLevel(sampler, uv, lod)手动指定 LOD。这会带来两个问题需要自己决定 LOD不具备各向异性过滤采样频率通常没有优势很多人直觉认为VS invocation 比 PS 少 → 采样更便宜但实际情况并不总是这样。原因VS 是per-vertexPS 是per-fragment如果 mesh tessellation 很高例如1M vertices而屏幕覆盖只有300k pixels那么 VS 采样反而更多。现代 GPU特别是 tile-based mobile GPU在 PS 端有更好的texture locality cache reuse。PS 具有明显的2x2 quad coherencepixel quadp0 p1p2 p3GPU 能预测邻近像素访问相邻 texel。VS 通常访问是vertex order in index bufferUV 分布往往是离散的因此cache miss 更频繁texture fetch latency 更高插值丢失细节VS 采样后传递给 PSfloat value tex.SampleLevel(...);output.value value;到 PS 会经过线性插值interpolated_value如果纹理变化很高频例如 normal map / height map会出现detail 丢失shading artifactPS 采样不会有这个问题。VS latency 更难隐藏一些技术里VS 采样反而是正确的做法1. Heightmap / Vertex Displacement典型例子terrain displacementwater wavesfloat h heightTex.SampleLevel(sampler, uv, 0);pos.y h * scale;只需要低频数据。Vertex Animation Texture (VAT)PS 有更好的quad-based locality关键点是 layout 一致性不只是“声明过就行”。在 Unity 的 SRP Batcher 体系下UnityPerMaterial的布局需要稳定。你现在 outline pass 虽然可能只真正用到_OutlineColor_OutlineWidth_OutlineZOffset但如果这个 shader 其他 pass 的UnityPerMaterial已经包含一整套字段那么为了避免不同 pass 对同一个 cbuffer 的解释不一致实践上通常会让各 pass 使用相同的一份UnityPerMaterial声明。所以你截图里把主 pass 的那一整串也写进来本质是在保证同名 cbuffer同字段顺序同对齐布局同 SRP Batcher 预期第三这不是为了“让 GPU 自动识别主 pass 的内存布局然后复用”那种意义上的“gpu布局”而是为了shader 编译期和运行时绑定的常量缓冲解释一致。HLSL 常量缓冲自身的打包规则。Unity / SRP Batcher 对UnityPerMaterial的约束。“布局”主要不是指 GPU cache line 或 wavefront occupancy 那种布局cbuffer内字段的offset / pack每个字段是否落在正确的16-byte register slot多个 pass 对同一个UnityPerMaterial的声明是否严格一致是否产生了明显的padding 浪费是否把更新频率不同的数据混放在一起以 16 字节为一个寄存器槽常量缓冲可以理解为按float4槽位切分一个槽 16 bytes变量会尽量往当前槽里塞塞不下就开下一个 16-byte 槽而hlslfloat3 a;float2 b;float3后剩 4 字节不够放float2所以b会跳到下一槽于是有 padding。所以一个最基本的审查动作是把每个字段按 16-byte slot 手工过一遍看有没有明显的碎片。第一原则所有 pass 的UnityPerMaterial必须完全一致这是最重要的 correctness 检查。你先不看节省空间先看这件事。一致的含义包括同一个CBUFFER_START(UnityPerMaterial)字段名字一致字段类型一致字段顺序一致哪怕只是某个 pass 少写了一个字段某个字段从float4改成half4顺序换了都可能让布局解释错位进而导致运行时读错值或者 SRP Batcher 退化。这是“优秀布局”的第一条不满足就直接不合格。最稳的做法还是把它抽到一个公共 include 文件里所有 pass 共用。Frame Debugger 看 SRP Batcher 是否稳定命中直接看 DXIL / DXBC 反射信息。可以通过“Show compiled code”或导出平台 shader再结合 DXC / DXIL reflection 工具看 buffer layout。对于熟悉 DX12 的人这一步最可靠。clip space zzc范围[-w, w]不是线性深度。NDC depthz_ndc zc / wD3D:[0,1]OpenGL:[-1,1]仍然非线性。linear eye depth这是 view spacez_view也就是-ViewPos.z或者 Unity 常见LinearEyeDepth这是线性的相机距离。所以关系是object → world → view → clip → ndc → depth buffer你这里改的是clip space不是 raw depth也不是 linear depth。裁剪空间里坐标是 positionCS (x, y, z, w)经过透视除法ndc positionCS.xyz / positionCS.w就进入 NDC。为什么z offset会导致当模型远离屏幕的时候会大块变黑因为你改的是投影后的深度不是物体真实位置。影矩阵 P 的内容本质上就是把 view space 里的点变成 clip space 的规则。对透视相机典型形式可以写成| A 0 0 0 | | 0 B 0 0 | | 0 0 C D | | 0 0 -1 0 |其中A 1 / (aspect * tan(fov/2))B 1 / tan(fov/2)C 和 D 由 near / far 决定不同图形 API、是否 reversed-ZC/D 的符号和具体形式会变它乘到 view space 点(xv, yv, zv, 1)之后得到xc A * xv yc B * yv zc C * zv D wc -zv关键点就在最后这句w -z_view所以透视除法后x_ndc (A * xv) / (-zv) y_ndc (B * yv) / (-zv) z_ndc (C * zv D) / (-zv)这就是“越远越小”的来源因为 x/y 最后都除以了深度。这也解释了你前面问的这句positionCS.z offset * positionCS.w;因为 w 大致和视空间深度成比例所以(zc offset * wc) / wc zc / wc offset这样能让 NDC 深度偏移接近常量。如果是正交相机投影矩阵就不是这种结构了通常更像| A 0 0 Tx | | 0 B 0 Ty | | 0 0 C Tz | | 0 0 0 1 |这时w 基本恒定是 1不存在透视缩小不需要靠乘 w 去补偿你如果问的是 Unity 里“实际用的 P 矩阵长什么样”那要再区分DirectX / Metal / VulkanOpenGLreversed-Z 开没开render texture 是否翻转所以在 Unity 里UNITY_MATRIX_P 的具体数值平台相关但结构和作用就是上面那套。最核心的内容你可以记成P 负责 1. x/y 按 FOV 和宽高比缩放 2. z 映射到深度范围 3. 把 w 设成和视空间深度相关用于透视除法在透视投影里w 和 view space 的 z 是直接绑在一起的。最核心的关系是w_clip -z_view这是最常见的透视投影形式。也就是说点离相机越远|z_view| 越大w_clip 也越大然后 GPU 做透视除法ndc clip / w于是x_ndc x_clip / w_clipy_ndc y_clip / w_clipz_ndc z_clip / w_clip所以 w 本质上就是“拿来做透视缩放的深度因子”。乘 w 的作用是把你在 clip space 里加的 z 偏移变成“透视除法之后近似恒定的 NDC 深度偏移”。你现在这句o.positionCS.z _OutlineZOffset * o.positionCS.w;如果不乘 w直接写o.positionCS.z _OutlineZOffset;那么最后进 NDC 时会变成z_ndc (z offset) / w z/w offset/w问题是近处 w 小offset/w 很大远处 w 大offset/w 很小也就是同一个 offset近处影响特别大远处几乎没效果这通常不稳定。而如果你写成o.positionCS.z _OutlineZOffset * o.positionCS.w;那透视除法后z_ndc (z offset*w) / w z/w offset结果就是无论远近在 NDC 里都近似加了同一个深度偏移因为远处时深度缓冲对“谁在前谁在后”的分辨能力会明显变差而 z offset 改的是投影后的深度排序不是几何真实位置。透视投影导致深度缓冲非线性分布远处深度分辨率极低再叠加 clip-space offset 被 w 缩小和 depth buffer 量化因此远处更容易出现深度冲突或 offset 失效。关键点mantissa 只有 23bit所以“相对精度”是固定的而不是“绝对精度”。相对精度ϵ2−23≈1.19×10−7\epsilon 2^{-23} \approx 1.19 \times 10^{-7}ϵ2−23≈1.19×10−7也就是说Δx≈x×2−23\Delta x \approx x \times 2^{-23}Δx≈x×2−23因此数值越大可表示的最小步长越大。举个更直观的例子数值范围最小间隔1.01.19e-7101.19e-610001.19e-41000000.0119所以在1 附近可以精确到0.0000001在100000 附近连0.01都表示不了这就是你看到的现象来源。Z-fighting深度冲突深度缓冲中的值如果落在同一个 float step 内就会被量化成同一个深度。典型情况两个三角形真实深度差0.00005depth buffer 在该范围的步长0.0001结果depthA depthBGPU 无法稳定决定前后顺序于是出现闪烁摩尔纹随视角变化的面片翻转这在以下场景尤其明显远距离地形coplanar decals阴影贴图大世界坐标抖动Large World Jitter当 world position 很大时小位移无法表示。示例float pos 100000.0此时 float 步长约≈ 0.0119如果角色移动pos 0.001结果pos 100000.0移动被量化掉。表现为摄像机 jitter物体微小振动animation skinning 抖动shadow map 不稳定因此很多引擎使用floating origincamera relative rendering所以之所以要使用z的精度问题/w顶点的数量顶点之间的插值float的精度问题处于其次影响在于顶点的不连续性数量实际上不够/w的clip space 近大远小屏幕空间里远处效果不稳定、覆盖异常、描边/偏移失真、Z-fighting 这类现象第一性原因通常不是 float 本身不够而是透视投影经/w后导致的空间分布非线性近处被放大、远处被压缩。这个压缩同时作用在深度分布、屏幕投影尺寸、顶点投影间距和三角形覆盖关系上。float 精度问题通常是放大器不是根因。Z 精度问题主要不是 float 在矩阵乘法过程中“不断损失精度”而是投影变换把 view-space 的深度通过一个非线性映射压缩到有限的 NDC/depth 区间里随后再量化到有限精度的 depth buffer。positionCSP⋅V⋅M⋅positionOS得到的是clip space坐标不是最终已经“塞进长方体”的坐标。真正进入标准长方体[-1,1]^3或 API 对应的 z 范围的是再做一次/w之后的 NDC。positionCSP⋅V⋅M⋅positionOS得到的是clip space坐标不是最终已经“塞进长方体”进入标准长方体[-1,1]^3或 API 对应的 z 范围是再做一次/w之后的 NDC。不是投影矩阵直接把顶点塞进同一个长方体而是它先把顶点映射到 clip space再通过 perspective divide 把不同距离的点非线性地压进统一的 NDC/depth 范围。它先把顶点映射到 clip space通过 perspective divide 把不同距离的点非线性地压进统一的 NDC/depth 范围。这个“压进去”的过程才是深度问题的关键。你的 fragOutline 返回的是纯色没有光照没有透明衰减没有基于视角的隐藏所以内部一旦被看到就是整块纯黑而 Blender 那边通常不一样你节点里有 Flip Faces这不是简单“剔除前面”是真的把壳体面朝向翻过来了结果是壳体的“外表面”在视觉上更合理Blender 视口经常默认不是完全按游戏里的实时 culling 方式显示可能开了双面显示可能有背面着色差异可能材质本身不是纯 unlit 黑色nity 里怎么等价做这个 Switch做法不是“在 HLSL 里复刻 Geometry Switch”而是把它降级成“参数分支”或“渲染组织分支”。对应你这张图最合理的落地是方案 A一个 Outline Pass里面用参数决定逻辑也就是不是切换两份 geometry而是切换两种“顶点位移规则”if (_UseMaterialFiltering 0.5) { widthMask * materialMask; } else { widthMask * 1.0; }这相当于把几何分支 A几何分支 B改写成同一份输入网格但用不同的 selection/mask 算法决定哪些顶点外扩这通常是最实用的 Unity 做法。方案 B拆子网格 / 拆材质如果 Blender 的 Material Selection 真的是按某个材质槽筛区域那 Unity 最稳的是把需要特殊描边的部分单独做 submesh或单独 renderer然后给它不同的 outline 参数这样你就不需要在 shader 里“切 geometry branch”了。很多项目里 brows 都是直接贴原色基本不参与常规光照尤其是二次元/风格化角色。常见原因很现实眉毛通常只是贴在脸上的一层信息不希望它跟着法线起伏被打亮打暗如果吃正常光照眉毛容易发灰、发脏、对比度不稳定面部表情和妆感更依赖“设计色”不是物理受光眉毛面积小但视觉权重高最怕被光照破坏形状和色值所以常见做法是直接采样贴图原色输出或只乘一个很轻的整体亮度或最多只吃一点环境光不吃主光方向项大概会是这种float4 brow SAMPLE_TEXTURE2D(_BaseMap, sampler_BaseMap, uv); return float4(brow.rgb, brow.a);或者稍微保守一点float3 color brow.rgb * _Brightness; return float4(color, brow.a);再多一点也可能是float3 ambient SampleSH(normalWS); float3 color brow.rgb * lerp(1.0, ambient, 0.2);但不会像皮肤那样认真做 NdotL、高光、阴影。尤其眉毛如果是face atlas 上的一块贴图单独贴片alpha 控制的 decal 式几何那更常见就是“按设计稿颜色直接出”。SampleSH的数据来源SampleSH实际读取的是 Unity 的Ambient Probe (Spherical Harmonics L2)RenderSettings.ambientProbe这个 probe 通常来自三个来源之一Skybox ambient lightingEnvironment Color/ GradientBaked GI / Light ProbeUnity 会把这些信息转成 SH 系数给shader。 Unity Documentation1shader 中读取unity_SHArunity_SHAgunity_SHAb...unity_SHCSampleSH只是对这些系数做ShadeSH9()运算。2 Lighting 窗口里的“开关”真正影响SampleSH的是Lighting → Environment LightingSource:SkyboxGradientColor如果是SkyboxUnity 会从 skybox 采样生成 SH。Gradient / ColorUnity 会把颜色转换成 SH。所以即使没有 skyboxSH 也不会是 0。3 Skybox 为空会怎样即使你把 skybox 设成NoneUnity 仍然会生成一个ambient probe。最常见情况ambient Environment Lighting Color所以SampleSH()仍然会返回值。Unity 文档里明确说明Unity 会生成 ambient probe 来保证默认情况下场景仍然有环境光。 Unity Documentation4 什么情况下SampleSH接近 0只有这些情况1 环境光颜色是黑色Lighting → EnvironmentSource ColorColor (0,0,0)SH 就几乎是 0。2 你手动c#清空 ambient probe代码RenderSettings.ambientProbe new SphericalHarmonicsL2();3 完全黑 skybox如果 skybox 是黑色 cubemap。5 与 LightProbe / Lightmap 的关系一个容易混淆的点SampleSH并不是 LightProbe。Unity逻辑if (LightProbeexists)-useinterpolated probe--else if (Lightmap exists)---usebaked GI----else-----useambientProbe也就是说ambient probe 是 fallback。Unity Documentation6 stylized shader 的常见保护写法因为 SH 有时候很暗所以很多 stylized shader 会 clampfloat3 ambient SampleSH(normalWS);ambient max(ambient, 0.3);或者float3 ambient SampleSH(normalWS);ambient lerp(1.0, ambient, 0.2);这样不会出现阴天 → 眉毛变灰7 一个很多人忽略的 runtime 细节如果你运行时修改 skyboxRenderSettings.skybox newSkybox;SH不会自动更新。必须调用DynamicGI.UpdateEnvironment();否则SampleSH还是旧值。8 一个风格化角色常见做法为了完全稳定眉毛/妆容颜色很多项目甚至不使用 SHfloat3 color baseColor * _FaceAmbient;而_FaceAmbient由角色系统统一控制。原因SH 会随着环境变化→ 角色脸色变化过大。有些角色脸在室外突然发绿 / 发蓝其实就是SampleSH normalWS的方向问题。这个在 stylized character pipeline 里非常典型。