3.4 KiB
3.4 KiB
Renderer模块 Material与Shader资产模型暂不满足SRP演进需求
1. 问题定义
当前资源层已经具备：
MaterialShaderTexture
但现有模型仍然偏“最小资源容器”，尚不足以直接承接未来 Unity 风格 Renderer / SRP 的完整需求。
当前最典型的问题是：
Shader更像“单个 stage shader 资源”Material更像“shader 引用 + 属性包”- 资产层缺少 pass / tag / render state / render queue 语义
2. 当前现状
从现有实现看：
Shader
当前 Shader 资源主要描述：
- shader type
- shader language
- source / compiled binary
- uniforms / attributes
这更接近“单个 shader stage 对象”，而不是面向渲染管线选择的 shader asset。
Material
当前 Material 资源主要描述：
- 一个
Shader引用 - 属性表
- 纹理绑定表
当前 MaterialLoader 也只解析最基础的 "shader" 字段。
3. 为什么这会影响未来 Renderer / SRP
在未来的 Unity 风格渲染体系中，Renderer / SRP 至少需要下列能力：
- 根据 shader pass/tag 选择绘制路径
- 区分 opaque / transparent / shadow caster / depth only 等 pass
- 用 render queue 控制排序层级
- 用 render state 描述 cull / blend / ztest / zwrite
- 为后续 keyword / variant 留空间
如果材质 / shader 资产模型长期停留在当前结构，会导致：
- 内建 forward 渲染可以临时跑起来
- 但未来一旦上 SRP，就必须大规模重构资源资产模型
这会影响：
- Renderer
- Material 资源格式
- Shader 导入格式
- editor 材质面板
- 未来 C# SRP 的 pass 选择逻辑
4. 建议方向
4.1 不要让 Shader 永远停留在“单 stage 资源”
后续建议演进到更面向渲染管线的概念，例如：
ShaderAssetShaderPass- 每个 pass 包含 vertex / fragment 等 stage 组合
- 每个 pass 具备 tag 与 render state 描述
4.2 Material 应逐步获得 renderer 需要的元数据
后续建议补充：
- render queue
- pass 相关 tag / override
- render state override
- shader keyword / variant 预留位
4.3 第一阶段可以先不一次性做全
但即使第一阶段只做 UnlitTexture / SimpleLit，也建议：
- 不把格式彻底写死成只有
"shader"这一个入口 - 为 future pass/tag 结构预留升级路径
换句话说：
- 当前阶段可以简化实现
- 但不能封死演进路线
5. 与 Unity 风格的关系
未来如果要在 C# 层做接近 Unity 的 SRP，shader pass 选择是核心能力之一。
例如：
ShaderTagIdDrawingSettingsFilteringSettings- renderer list / pass filtering
这些能力都要求材质与 shader 资产层至少能表达“pass/tag/state”。
因此，这个问题虽然不一定是 Renderer v0 第一周就要全量解决，但必须在设计阶段明确记录。
6. 建议验收标准
进入下一阶段时，至少应达到以下其中一档：
档位 A：最小可演进
- 明确存在“shader pass”概念
- 材质资产格式有升级空间
- 内建 pipeline 能按 pass 选择绘制
档位 B：更接近 SRP
- 具备
pass + tag + render state + queue - 为 future keyword / variant 留接口
7. 优先级
中到高。
它不一定阻塞 Renderer v0 的第一步落地，但如果完全忽略，未来做 C# SRP 时会出现明显返工。