自由学习记录（59）

✔ ShaderLab

└── defining a Shader object

└── defining a SubShader

└── defining a Pass

└── adding shader programs

└── commands（用于配置状态）

✔ HLSL in Unity

└── 核心语言：变量声明、矩阵变换、光照计算、纹理采样等

`Stencil` 是哪个层级的？

属于 ShaderLab 的 Pass 块中 Commands 层
和 ZTest、ZWrite 是同级的像素级状态控制指令
是在 GPU rasterization 后、fragment shader 执行前 执行的

层级	负责什么
`ShaderLab`	包裹整个 Shader 的结构与状态配置
└── `Commands`	设置渲染管线的状态（Stencil、ZTest）
└── `Stencil`	控制像素是否允许渲染/写入
`CGPROGRAM`	包含实际执行的 vertex/fragment shader
`HLSLCode`	完整的计算逻辑、光照、纹理等

By default, the GPU writes to all channels (RGBA).

Offset 的本质是什么？

它不是视觉上的移动，而是让 GPU 对"Z 值"加一个偏移，从而影响 ZTest 和 ZWrite 的判断结果。

"RenderType"="Opaque" 有什么用？

这是 Unity 在做 后处理、阴影、光照、剔除等内部优化分类时的标记。

它不是决定 Shader 渲染行为的关键，而是：

给 Unity 的渲染系统或后处理系统一个分类提示，比如：

是否参与阴影贴图渲染
是否进入后处理剔除流程
SRP Batcher 是否批处理它等

Rasterization（像素生成）

↓

Stencil Test ←←←← 你设置的这段代码起作用在这里！

↓（通过才继续）

Depth Test (ZTest)

↓

Fragment Shader

↓

Color/Depth Buffer 写入

Stencil Buffer 在每一帧的开始阶段（或每个相机渲染阶段）会被清空，默认值是 0。

三个关键阶段（Stencil 操作类型）：

阶段	触发条件	含义说明
`Pass`	stencil test ✅ 且 depth test ✅	片元通过 stencil + 深度测试
`Fail`	stencil test ❌	stencil 不通过
`ZFail`	stencil ✅ 但 depth ❌	stencil 通过，但被深度测试剔除

操作选项说明（你图中提到的每一项）

操作名	中文含义	数值行为 & 举例
`Keep`	保持原值	不修改 stencil buffer（最常见）
`Zero`	写入 0	抹除区域常用
`Replace`	写入 Ref 值	最常用的写 stencil 的方式
`IncrSat`	增加 1（饱和）	`254 → 255 → 255`（不会超）
`DecrSat`	减少 1（饱和）	`1 → 0 → 0`（不会负）
`Invert`	位取反	`00000001` → `11111110` = 254
`IncrWrap`	增加 1（循环）	`255 + 1 → 0`（超出变 0）
`DecrWrap`	减少 1（循环）	`0 - 1 → 255`（下溢变 255）

应用建议：

操作组合	用途
`Comp Always` + `Pass Replace`	写入 stencil mask 区域
`Comp Equal` + `Pass Keep`	只让特定 stencil 区域可见（不写入）
`Pass IncrSat` + `ZFail DecrSat`	分层地刷 stencil 计数（如地形穿插特效）
`Pass Zero`	清除模板值区域

关掉 ZWrite， 依然可以写入颜色缓冲区，只要你的片元通过了 ZTest 且启用了 ColorMask 和 Blend。

设置	行为
`ZTest Always`	所有片元都通过测试 → 能继续执行 Fragment Shader、写颜色
`ZTest LEqual`	通过 Z 比较判断是否绘制（常用）
`ZTest Never`	所有片元都不通过测试 → Fragment 不执行 → 不写颜色
❗`ZTest Off`（非法）	Unity 实际上不会接受这个值，结果和 `ZTest Never` 类似，物体消失

Unity 渲染顺序排序规则（按优先级）：

RenderQueue 值（数值小的先渲染）
Material 的 Shader Pass（Tag）顺序
Material 实例 ID（material 被创建的先后）
MeshRenderer 的 Sorting Layer / Order（如果启用 SRP）
对象在 Hierarchy 中的顺序（具体实现非公开，但确实存在影响）
可能的优化批处理合并顺序（例如 SRP Batcher）

Designed for both realistic and stylized lighting

Basic physically-based rendering (PBR)

Easier to customize for custom lighting models such as cel shading

Unlike traditional ray tracing, which calculates exact intersections with geometric primitives, ray marching relies on signed distance functions (SDFs) to determine the distance from a point in space to the nearest surface.

Ray marching is a rendering technique that determines the intersection of rays with objects in a scene by advancing the ray in steps, guided by a Signed Distance Function (SDF).

Advancement: The ray advances by the evaluated distance. This process repeats until the distance is below a small threshold (indicating a surface hit) or a maximum number of steps or distance is reached (indicating no intersection).

Shading: Once an intersection is found, lighting calculations are performed to determine the color of the pixel.

This method is efficient because it avoids unnecessary calculations and can handle complex, procedurally defined scenes without explicit geometry.

LDR = Low Dynamic Range，低动态范围图像

通常指的是 8-bit 每通道 的图像格式，比如：

.png（常见的 UI 图像）
.jpg（压缩的贴图）
Unity 中大多数非 HDR 图像默认就是 LDR

"LDR 转码"可能指什么？

情况 1⃣：在渲染流程中转换为 HDR 使用

即：将 LDR 图像内容提升到 HDR 流程中，比如做后期处理、Bloom 等

这时，Unity 或 Shader 中需要将 LDR 色值（0~1）：

转换为 线性空间
有时还要乘上曝光系数、Gamma 校正等

因为 LDR 渲染没有亮度爆炸 （所有颜色都压缩在 0~1），如果用 One One 累加容易溢出导致伪高光。

而 HDR 渲染可以存储 >1 的颜色 ，就允许你用 Blend One One 来叠加多个高亮源，实现自然的"亮区溢出"效果。

Shader 中的 HDR 模式是 针对渲染管线，不是贴图文件本身

所谓的"LDR 模式"和"HDR 模式"并不是直接判断图片是不是 HDR 图片，而是这个 Shader 是否运行在 HDR 渲染目标上（例如后处理的 RT 支持高亮度值 >1）

#pragma multi_compile __ UNITY_HDR_ON

如果你在 ForwardAdd / Deferred / PostEffect 中使用 HDR Framebuffer（比如 RenderTexture 设置了 HDR 格式如 ARGBHalf），那么 UNITY_HDR_ON 就会被启用。

图片格式会直接影响 Shader 中是否能产生或承载 HDR 效果，但它的作用不是决定 HDR 渲染"开不开"，而是决定：

贴图本身是否能存储和输出 HDR 色值（即 >1.0 的亮度信息）

渲染流程中的 HDR 有两个维度

类型	控制作用	举例
渲染目标是否 HDR	控制最终 framebuffer 是否允许 HDR 值	摄像机开启 `allowHDR`，RenderTexture 用 `ARGBHalf`
贴图格式是否 HDR	控制图片是否存储了 HDR 内容	`.exr` 图，高光范围 >1.0

贴图格式	是否支持 HDR	说明
`.png`, `.jpg`, `.tga`	❌ 否	LDR，颜色范围最大为 0~1
`.hdr`, `.exr`	✅ 是	支持 float 数据，值可 >1（如阳光 10.0）

用了 .png 图片，即使你后面 col * 100.0 也不叫 HDR 图。因为原始值已经被压缩死了。
你用了 .exr 并且在导入时设置为 RGBAHalf，它才是真正的 HDR 图源。

Shader 中怎么才能体现 HDR 效果？

必须三者都满足：

✅ 渲染目标是 HDR

摄像机 allowHDR 开启，或者你使用了 RenderTextureFormat.ARGBHalf
✅ 贴图本身是 HDR 图（如 .exr）

导入时设置格式为 RGBAHalf 或 RGBAFloat
✅ Shader 中不被 Gamma 或 ToneMapping 限制
- 使用 Blend One One
- 不用 saturate/clamp
- 最终走 PostProcess 才看到溢光 Bloom

位数（每通道）	存储内容	亮度范围	示例格式
8-bit	存整数 0 ~ 255	实际映射为 0.0 ~ 1.0	PNG, JPG
16-bit float（half）	存浮点值（可大于 1）	支持 HDR，如 3.2, 10.0	`.exr`, ARGBHalf
32-bit float（full）	更高精度 HDR	如 0.0001 ~ 100000	`.exr`, ARGBFloat

Unity 不会也不能真正 把 .jpg / .png 这样的 LDR 图片"变成" HDR 图片，原因在于：

✅ LDR 图（如 .jpg/.png）在磁盘上就已经失去了 HDR 信息，Unity 无法凭空生成。

HDR 图片资源 和LDR 图片资源 在 Unity 中的显示会有明显不一样的效果 ，但前提是你使用的是"支持 HDR 的渲染管线与设置"。否则，即使你导入了 HDR 图，也会被当作普通贴图对待而失去意义。

📌 如果你只是把 HDR 图（如 .exr）当作一个普通贴图 MainTex，贴在一个物体上，不使用 HDR 相机、不经过后期处理（如 Bloom），那么：

➤ 它的显示效果会看起来和 `.png` 几乎没区别！

这是因为：

屏幕是 LDR 输出设备（0~1），高亮值被裁剪或 tone map 掉了
你没使用 HDR 渲染目标 → 无法表达高于 1.0 的值
Shader 最终输出的是 SV_Target 限制在 [0,1]

在HDR 渲染 + 后期（Bloom）等开启时，HDR 图效果显著不同！

在如下条件下，HDR 图像的高亮值会被正确渲染出来：

✅ 条件一：相机 `Allow HDR` 开启

在 Unity 相机设置中勾选：

[✔] Allow HDR

✅ 条件二：使用了 Bloom / Glow 等后处理（Post Processing）

例如使用 Unity 的 Post Processing Stack 中的 Bloom ，当图片中有亮度 >1 的区域时，会：

显示明显的溢光（Bloom）
显示能量更高的区域发光
呈现出一种"高动态"的感觉

都是刚导入unity的图片--默认格式

.hdr .jpg

延迟渲染之所以要"分多个 Render Target"，是因为它先要"收集物体的物理属性"，再统一"光照计算"，所以必须把各种表面信息分别存起来。

Forward 渲染是"画一个人 → 给他涂光影 → 下一个人"，

而 Deferred 渲染是"先画所有人的轮廓、材质、法线 → 最后一次性打灯照亮整个场景"。

Deferred 渲染的第一步就是把你所有看得见的物体的这些"物理表面信息"写进几个专用的缓冲区（Render Targets）里，这组缓冲我们称为：

✅ G-Buffer（Geometry Buffer）

✅ 为什么不能把所有数据塞进一个 Target？

因为：

Render Target 通常是 RGBA（4 通道 float）
一个 Target 最多装下 4 个 float 值
法线是 3D 向量（3 个 float）
颜色 + 粗糙度 + 金属度 是 4 个 float
加起来根本装不下

这叫：

✅ MRT（Multiple Render Targets，多渲染目标输出）

（RT = RGBA4 通道）

在延迟渲染路径下 ，半透明物体不是"完全不能渲染"，而是：

✅ 不能参与延迟光照计算 ，但可以在延迟路径后以 Forward（前向）方式额外渲染补上透明部分。

这点是延迟渲染架构的一个"混合渲染设计"。

为什么延迟渲染不支持半透明物体参与主流程光照？

核心原因：

延迟渲染中光照计算发生在 每个屏幕像素上（Screen-Space），但：

半透明物体的特性	延迟渲染难以支持的点
颜色和光照需要与背后的物体混合	GBuffer 只能记录一个片元（最前的那一个）
多个物体沿深度重叠、需逐层混合	延迟渲染只保存每像素最前面的信息
常用 Alpha Blending（如加法/乘法）	无法在 GBuffer 中保留多个深度层

因此，半透明物体无法写入 GBuffer 并延迟光照处理。

Unity 是怎么解决的？

Unity 的做法是：

✔ 延迟渲染管线结构：

Opaque（不透明）物体 → Deferred Pass：主流程，输出 GBuffer，执行光照计算
Transparent（半透明）物体 → Forward Pass：绕开延迟流程，单独计算光照+混合

你在使用延迟渲染时，其实透明物体仍然被渲染，只是：

不进 GBuffer，不参与延迟的光照阶段
走的是 ForwardBase Pass
支持 Alpha Blending，手动计算光照

所以你可以看到半透明的水面、玻璃、粒子效果 仍然存在。

如何验证？

你可以在 Frame Debugger 打开一个延迟渲染项目，然后查看：

GBuffer Pass 写入的对象是 Opaque 类型
半透明物体（带 Alpha 或透明队列）会在 GBuffer 后走 Forward Pass
Shader 的 Tag 里写着 "LightMode" = "ForwardBase"

Tags { "Queue" = "Transparent" "RenderType" = "Transparent" "LightMode" = "ForwardBase" }

Blend SrcAlpha OneMinusSrcAlpha

这会让你的 Shader：

在延迟渲染中作为 Forward Pass 插入

得到单独计算的光照（但性能取决于光源数量）

所谓"正常显示"的意思是：

肉眼可见的内容，在屏幕上确实绘制出来了，半透明的效果也看起来"对"，没有消失，也能混合、贴图、反射、水波等等------这就是"看起来正常"。

比如：

玻璃材质确实半透明，看得见背后
粒子烟雾确实飘着，看起来和 Forward 渲染没什么不同
水面波动有 Fresnel 高光，看起来很漂亮

问题 1：延迟渲染的 GBuffer 无法支持多个片元（透明层）

延迟渲染在 GBuffer 中，每个像素只能存储：
- 一个颜色（albedo）
- 一个法线
- 一个深度
- 一个高光参数......
但：
- 透明叠加（如玻璃 + 水 + 烟雾）需要 多层数据
- 延迟渲染只能记录最前面的那一层

结果：

❌ 后面的透明层被彻底"丢弃"，你看到的只是最前面的一层，无法正确混合

无法使用透明混合（Blend）

延迟渲染阶段是全屏后处理（屏幕 Quad）
这个阶段已经不是 per-object 渲染了
Unity 的延迟光照 Pass 不支持混合模式（Blend）
而 Alpha Blend 依赖深度排序和混合

结果：

透明的加法、乘法、Alpha 衰减等效果全部无法执行

问题 4：多个透明物体重叠会严重错误（没有 Painter's Algorithm）

Forward 渲染透明是靠"按从后往前绘制"来模拟层叠
Deferred 中 GBuffer 阶段是"按深度近处优先"
所以即使你硬塞透明物体进去，ZTest 会挡掉后面的半透明层

定义一个"半透明物体"的本质是：

👉 这个物体的最终像素颜色，依赖于它后面的像素的存在，它需要和后面合成。

只要存在这种依赖，"你就不是个能走延迟管线的老实物体"，而必须被分出去单独处理。

Unity 判断 Shader 是否应该转入 Forward 路径而不是延迟光照，主要依据以下"硬条件"：

条件	解释
`Blend` 指令是否存在	✅ 一旦存在混合操作（如 `Blend SrcAlpha OneMinusSrcAlpha`），将强制切换到 Forward
渲染队列（Queue）是否是 Transparent 类别	✅ 若 `Queue = Transparent`（3000+），一般也会走 Forward
`ZWrite` 是否关闭	关闭 ZWrite 是常见透明标志，和 Blend 搭配使用
`Alpha` 通道是否参与输出	只写透明色（例如输出 alpha < 1）也会被视为"透明物体"
光照模式 `LightMode` 是否兼容 Deferred	Deferred 只接受特定的 LightMode（ForwardAdd 会强制转 Forward）

cs 复制代码

Tags { "RenderType" = "Opaque", "Queue" = "Geometry", "LightMode" = "Deferred" }
Blend SrcAlpha OneMinusSrcAlpha  // ❗ 触发转 Forward
ZWrite Off

// 即使你写了 LightMode = Deferred，Unity 仍会忽略这一 Pass 的延迟处理

UNITY_LIGHT_ATTENUATION 是 Unity 在其内置光照宏系统中用于处理光照衰减与阴影遮蔽的一个宏定义，它会根据当前的渲染模式（如 ForwardBase / ForwardAdd）自动计算光源的衰减（Attenuation）以及是否处于阴影中。

atten = SHADOW_ATTENUATION(i); // 阴影遮蔽系数，0 表示全阴影，1 表示无遮挡

atten *= LIGHT_ATTENUATION(i); // 距离、角度等造成的光照衰减

它已经包含了：

距离衰减（Distance Attenuation）
点光/聚光角度衰减（Spotlight attenuation）
阴影遮蔽（Shadow attenuation）

UNITY_LIGHT_ATTENUATION(atten, i, i.worldPos);

atten：输出变量，用于存储光照衰减结果。

i：插值结构体（v2f），它包含阴影坐标、光照坐标等。

i.worldPos：当前像素的世界空间位置。

一般你在 ForwardBase/ForwardAdd 的片元光照计算中，写自己的 Lambert 或 Blinn-Phong 模型前会调用这个宏