自由学习记录（132）

SRP 不能做的本质是：

"把 Unity 的 Camera 组件机制换掉"

比如你不能让 Unity 不再依赖 Camera、完全用你自己的自定义组件直接接管引擎底层相机系统。

所以如果你问的是：

"SRP 能不能定义一套完全脱离 Camera Component 的相机系统？"

通常不行，至少不是按 Unity 这套标准 SRP 用法来做。

SRP 可以做的：

读取 camera.fieldOfView

读取 camera.cullingMask

读取 camera.clearFlags

读取 TryGetCullingParameters

根据不同 camera 走不同渲染逻辑

甚至直接在运行时改 camera.xxx 的值

SRP 不能做的本质是：

"把 Unity 的 Camera 组件机制换掉"

比如你不能让 Unity 不再依赖 Camera、完全用你自己的自定义组件直接接管引擎底层相机系统。

等编译的时候回答问题///

脸部阴影非常小且精细 。

头发在脸上形成的阴影通常是：

很细的发丝
很小的遮挡
非常靠近表面

例如刘海压在额头上那种阴影。

如果用普通 ShadowMap：

阴影贴图是从光源投影
分辨率固定
texel 覆盖世界空间面积

结果就是：

头发投到脸上的阴影只占几个 texel。

于是就会出现：

阴影锯齿
抖动
泳动
阴影断裂

阴影发生在非常近的距离。

头发和脸的距离可能只有：

复制代码

1mm ~ 1cm

但 ShadowMap 是在光空间采样：

复制代码

shadow_depth - receiver_depth

这种情况下：

bias 很难调
容易 acne
或者 peter-panning

尤其头发这种 薄几何体 会更明显。

第三，卡通脸部阴影其实不是物理阴影。

很多动画 / 游戏里，头发投到脸上的阴影是 艺术控制的效果：

例如：

阴影形状固定
不完全随光变化
保持脸型好看
防止眼睛被遮住
保证表情清晰

如果完全依赖 ShadowMap：

复制代码

光方向变化 → 阴影完全变化

就会破坏角色表现。

所以很多项目会用 非真实阴影方案。

常见 trick 包括：

1. Ramp Shadow / Face Shadow Texture

在脸上用一张 mask：

复制代码

dot(N,L) + mask

控制阴影区域。

例如：

复制代码

脸左侧暗

脸右侧亮

并且和头发位置关联。

引擎很多系统都依赖 Camera

不只是渲染在用 Camera，还有：

SceneView

GameView

剔除

输入射线

Gizmos

后处理挂接

多相机排序

渲染目标

编辑器预览

这些都建立在 Camera 组件体系上。

如果 SRP 能随便替换 Camera，本质上就是允许你重写一大块引擎基础设施，Unity 并没有把权限开放到这一步。

真正需要"彻底替换 Camera 组件模型"的用户非常少。

大多数人只需要：

自定义渲染流程

自定义后处理

自定义 Pass

自定义相机控制逻辑

这些 SRP + 额外脚本已经够了。

Unity 没必要为了少数极深度用户，把整套核心对象系统开放出去。

Camera 在底层替你做的，核心就是两类事：定义"怎么看"，以及把这个"看法"接进 Unity 整个引擎系统。

具体可以分成这些。

定义观察空间

它帮你维护：

位置和朝向

视锥体

FOV / 正交尺寸

near / far clip

投影矩阵

viewport rect

也就是"从哪里看、看多大范围、按什么投影看"。
提供剔除基础

Camera 会把和观察有关的剔除条件组织好，供你通过：

TryGetCullingParameters

拿出来用。

也就是它帮你把"这台相机理论上能看到什么"整理成统一输入。

维护渲染目标语义

比如这台相机要画到：

屏幕

RenderTexture

某个目标缓冲

还有深度、排序、叠加关系、多相机输出这些语义，都是 Camera 这层在组织。

虽然 SRP 可以不照它默认来做，但 Camera 本身还是维护了：

clear flags

background color

depth

HDR/MSAA 相关选项

stacking/输出优先级相关信息

这些都是"相机级渲染意图"。
和引擎其他系统对接

Camera 提供的是一套统一的"观察接口"，运行时和编辑器里的很多系统都围绕这套成员工作。

比如同一套东西会被反复使用：

位置和朝向

投影参数

near/far

viewport

clear 相关设置

目标纹理

坐标转换接口

剔除参数来源

这样带来的好处是：

语义统一

不管是 Game、Scene、预览窗口，大家谈的都是"相机怎么看"。
系统可复用

很多功能不需要为运行时和编辑器各写一套完全不同的观察模型。
工具链更稳定

输入、Gizmos、预览、渲染调试都能挂在这套统一接口上。

既然有泛型了，这里为什么要pipeline shader tag？

因为这两者解决的不是同一个问题。

RenderPipelineAsset<BasicRenderPipeline>

是给 C# 类型系统和 Unity 运行时用的

它表达的是：

"这个 asset 会创建哪种 RenderPipeline 类"

而：

private const string RenderPipelineShaderTag = "LightweightPipeline"; public override string renderPipelineShaderTag => RenderPipelineShaderTag;

是给 shader 系统和构建流程用的

它表达的是：
"哪些 shader 认为自己属于这条渲染管线"，必须给自己加上这个标签，防止错配，就和urp的shader里写urp tag才可以被加入渲染流程是一样的

大方向是对的，但要再收紧一点表述。

更准确地说：

RenderPipeline tag 主要是声明"这个 Shader 面向哪条管线"
比如：

Tags { "RenderPipeline" = "LightweightPipeline" }

renderPipelineShaderTag 是你的 SRP 在 RenderPipelineAsset 里给出的"当前管线标识"
Unity 会拿这两个值做匹配，主要用于：

shader 归属识别

variant stripping

构建时筛选

所以你说的"防止错配"是对的。

但有一点要区分：

它不等于"只有写了这个 tag 才能被加入渲染流程"

真正++决定某个 Pass 会不会被画到的++，是你在渲染代码里用的 ShaderTagId，比如：

++new ShaderTagId++("SRPDefaultUnlit")

这是"Pass 级别匹配"。

而 RenderPipeline = "LightweightPipeline" 是"Shader 级别归属"。

所以：

泛型解决的是：

代码里的类型绑定

shader tag 解决的是：

shader 资源归属识别

为什么泛型不能代替 shader tag？

因为 shader 不是 C# 泛型对象。
ShaderLab / shader variant stripping / 构建流程不会靠 BasicRenderPipeline 这个 C# 类型名自动推断归属，它们需要一个明确的字符串标识去对齐，例如：

Tags { "RenderPipeline" = "LightweightPipeline" }

Unity 会拿 shader 里的这个字符串，去和 renderPipelineShaderTag 对比。

所以这两层关系是：

RenderPipelineAsset<BasicRenderPipeline>
告诉 Unity 代码层："你会创建哪个管线类"

renderPipelineShaderTag

告诉 Unity shader 层："哪些 shader 属于这条管线"

一句话：

泛型管 C# 类型关系，shader tag 管 shader 归属关系，两个都不能互相替代。

写 SRP 时，context 基本就是你和 Unity 渲染后端打交道的主接口之一。

头发投到脸上的阴影只占几个 texel。这个问题是srp可以解决的吗？首先，Camera组件是固定的，context是接渲染后端，阴影的形成，一次性看整个view box 深度，

单独挑出部分物体，渲染更精确的shadowmap？

这个要做，要更了解shadow的流水线

复制代码

if (pixel 在头发投影区域)

darken

而不是 shadow map。

Hair Shadow Map（单独一张）---这是可以的

只让头发投影到脸：

复制代码

render hair → small shadow map

apply only to face

这样分辨率集中在脸部。

复制代码

脸阴影 = 手绘 mask

只根据光方向切换几种版本。

例如：

front light

side light

back light

ShadowMap 适合：

复制代码

建筑

地面

大物体

远距离

但不太适合：

复制代码

头发 → 脸

睫毛 → 眼睛

衣领 → 下巴

这种 极小遮挡 + 高艺术要求 的情况。

Tonemap（色调映射）在卡通渲染里的取舍。核心意思是：

标准 ACES Tonemap 对卡通渲染往往"过重"，会破坏颜色风格，因此很多卡通项目会降低 ACES 强度，或者直接使用更简单的 Tonemap。

物理亮度、人眼感知与显示设备特性之间的三重矛盾。

RGB数码形式：颜色的数字化编码

计算机中的像素颜色通过RGB三通道数值定义，例如8位系统中每个通道取值范围为0-255（对应0-1的归一化亮度）。这些数值本质是对物理光强的线性采样结果，即数值翻倍理论上代表光强翻倍。但直接使用线性数据会暴露两个问题：

存储效率低下：8位精度下，线性编码会将55%的灰度级分配给人眼不敏感的高亮区域，导致暗部细节丢失；
显示失真：CRT及现代显示器（如LCD/OLED）的输出亮度与输入电压呈非线性关系（近似亮度=电压^2.2），直接输入线性RGB会使图像整体偏暗。

Gamma校正：非线性补偿的双重作用

Gamma校正通过幂运算对RGB数值进行非线性转换，形成"预补偿-显示补偿"的闭环：

预补偿（编码阶段）：将线性RGB转换为非线性的sRGB空间，公式为非线性值 = 线性值^(1/2.2)。例如线性亮度0.218经此转换后变为0.5，使8位存储中暗部细节从55级提升至128级，匹配人眼对暗部更敏感的特性（韦伯定律）。
显示补偿（解码阶段） ：显示器通过自身Gamma曲线（约2.2）将sRGB数值还原为线性亮度，即输出亮度 = sRGB值^2.2。例如存储的0.5经显示器转换后恢复为0.218的物理亮度。

也就是说rgb的颜色定义理论是在硬件显示之上的

所以图片的显示方式才可选择是否srgb

现代显示中的Gamma校正实践

硬件实现：显示器驱动芯片（如OLED的DDIC）通过Gamma查找表（LUT）优化转换效率，针对不同亮度等级（如低亮度采用PWM与电流混合驱动）动态调整参数。
软件适配：游戏引擎（如Unreal）需在光照计算前将sRGB纹理转换回线性空间，避免光照叠加错误（例如线性空间中0.5+0.5=1.0，而sRGB空间中0.5+0.5会导致过亮）。
HDR扩展 ：高动态范围内容虽使用32位浮点存储线性亮度，但最终仍需通过Tonemapping压缩至sRGB范围后，应用Gamma校正以适配显示设备。

计算的过程就是一直处于"少了符合人眼敏暗"的线性计算，所以最后才额外要^2.2，也就是gamma去压低

因为都是在01之间，所以压低

渲染中计算的颜色值叫做 scene-referred 的。把经过 tonemapping 转换后的值叫做 **display-refrerred。**tonemapping 也叫做Display rendering Transform 或者 Output Transform。tonemapping 也叫做Display rendering Transform 或者 Output Transform。

在 CG、影视和游戏开发中，ACES（Academy Color Encoding System）与 Tone Mapping（色调映射）的关系可以概括为：ACES 是一个完整的色彩管理系统，而其核心组成部分之一就是一套标准化的 Tone Mapping 方案。 [1, 2]

简单来说，ACES 决定了"色彩如何流动"，而 Tone Mapping 决定了"高亮度如何被压缩到显示器能显示的范围"。 [3, 4]

1. 包含关系：ACES 是框架，Tone Mapping 是工具

ACES：是一个行业标准框架，涵盖了从摄影机输入（IDT）、中间合成（ACEScg）到最终输出（ODT）的全过程。
Tone Mapping：是 ACES 输出转换（Output Transform）中的一个核心数学步骤。由于渲染出的 HDR 画面亮度极高，远远超过普通显示器（sRGB/Rec.709）的承载能力，必须通过 Tone Mapping 将这些超亮信息"映射"回可显示的范围。 [1, 4, 5, 6, 7, 8]

2. 功能特点：为什么常用 ACES 做 Tone Mapping？

相比传统的"线性映射"或简单的 Reinhard 映射，ACES 的 Tone Mapping 具有以下特点：

胶片感（Filmic Look）：ACES 的映射曲线呈 S 形，模拟了胶片的感光特性，能产生更强的对比度和自然的色彩饱和度。
高光收敛（Highlight Compression）：它能有效防止亮部直接"炸掉"变成纯白。在 ACES 映射下，极亮的颜色会逐渐向白色过渡，并保留一定的细节和色彩倾向。
一致性：通过使用 ACES 标准，你在 Blender、Unreal Engine 或 Nuke 中看到的画面效果可以保持高度一致。 [8, 9, 10, 11, 12, 13]

3. ACES 流程中的关键节点

在 ACES 体系内，Tone Mapping 主要发生在以下两个阶段的组合中：

RRT (Reference Rendering Transform)：这是 ACES 的"灵魂"，它将 HDR 场景数据转换为一种理想化的、极宽动态范围的图像，其中包含了基础的 Tone Mapping 曲线。
ODT (Output Device Transform)：针对特定显示器（如你的电脑屏幕）进行最后的适配。 [4, 7]

在 Unreal Engine 中配置 ACES 色彩空间？
比较 ACES 与新流行的 AgX Tone Mapping 有什么区别？