72 lines
2.1 KiB
Markdown
72 lines
2.1 KiB
Markdown
# Renderer 阶段收口补充：Object ID Picking 正式化
|
||
|
||
日期：`2026-04-02`
|
||
|
||
## 1. 这次补充收口解决什么
|
||
|
||
本次补充只收一件事：
|
||
|
||
- `SceneView` 选中主链路正式切到 `GPU object-id`
|
||
|
||
本次明确不做：
|
||
|
||
- render graph
|
||
- renderer 内更完整的多 pass 调度
|
||
- game/runtime 通用 picking 服务
|
||
|
||
原因很简单：这些属于下一阶段架构演进，不应该继续污染当前阶段的收口边界。
|
||
|
||
## 2. 本次收口后的正式行为
|
||
|
||
当前 `SceneView` 选中行为统一定义为：
|
||
|
||
1. 场景渲染时生成 `object-id` 纹理
|
||
2. 鼠标点击时读取对应像素
|
||
3. 颜色解码为实体 ID
|
||
4. `0` 视为“未选中任何对象”，但这仍然是一次成功的 GPU 采样
|
||
|
||
关键变化：
|
||
|
||
- editor 不再把 `CPU ray picking` 作为 `SceneView` 点击选中的静默回退主链路
|
||
- `CPU ray picking` 继续保留为独立几何工具能力，不再承担当前正式选中流程
|
||
- `object-id` 读取失败会被显式标记为 readback failure，而不是与“没有有效帧”混在一起
|
||
|
||
## 3. 为什么这才算收口
|
||
|
||
之前的问题不是没有 `object-id pass`，而是“主路径”和“兜底路径”的语义不够硬：
|
||
|
||
- 成功采样
|
||
- 无有效 object-id 帧
|
||
- GPU 读回失败
|
||
|
||
这三种状态以前没有被清晰区分。
|
||
|
||
现在已经收紧为显式结果类型：
|
||
|
||
- `Unavailable`
|
||
- `Success`
|
||
- `ReadbackFailed`
|
||
|
||
这意味着：
|
||
|
||
- renderer/editor 的 `object-id` 交互已经形成可测试契约
|
||
- `0 id` 与“采样失败”不再混淆
|
||
- 后续若要继续升级成异步 readback、共享 picking 服务，也有稳定边界可接
|
||
|
||
## 4. 当前阶段完成后的边界
|
||
|
||
到这里，当前阶段可以正式视为完成：
|
||
|
||
- editor viewport 宿主链路已打通
|
||
- renderer 的 builtin post-process 已形成稳定接口
|
||
- `SceneView` 选中正式以 GPU object-id 为主链路
|
||
- 回归测试已覆盖 object-id 读回状态语义
|
||
|
||
下一阶段真正该做的是：
|
||
|
||
- renderer 内正式 render graph / pass graph
|
||
- 更完整的 renderer-owned picking 服务
|
||
- editor / runtime shared picking contract
|
||
|
||
而不是继续在这个阶段里反复修补 viewport host。
|