XCEngine/docs/used/EditorViewport宿主渲染收口总结4.1.md

Editor Viewport 宿主渲染收口总结 4.1

当前判断

截至 2026-04-01，这一阶段的主线应视为：

• 把 Editor -> ViewportHost -> Renderer -> RHI 这条链路接通
• 把 editor viewport 的宿主层从 panel 内部逻辑中收出来
• 把这层宿主代码压到“可继续演进，但先停止扩张”的状态

这一阶段的目标不是继续往 editor viewport 里塞更多功能，也不是提前做完未来 renderer 的全部能力。

如果继续在本阶段里混入 gizmo 完整体系、GPU picking 正式方案、多 pass 大改、后处理、光照系统等内容，只会让阶段边界再次失控。

已完成的收口结果

1. editor viewport 已经不再是空壳

当前 SceneView 与 GameView 已经能通过统一的 viewport host 路径请求离屏 render target，并把 renderer 输出展示到 editor 面板中。

当前已实际接通：

• Scene viewport 渲染
• Game viewport 渲染
• viewport resize 资源重建
• backpack 等真实模型内容在 editor 中显示
• grid / 选中 / 描边 / object id 读取链路

2. viewport host 的职责边界已经成型

当前 viewport 宿主层已经被拆成几块相对明确的职责：

• editor/src/Viewport/ViewportHostSurfaceUtils.h
  • viewport surface / texture / reuse 相关纯工具
• editor/src/Viewport/ViewportHostRenderTargets.h
  • viewport render target 生命周期与创建销毁
• editor/src/Viewport/ViewportObjectIdPicker.h
  • viewport object id 读取与像素映射
• editor/src/Viewport/ViewportHostRenderFlowUtils.h
  • scene/game viewport 的失败回退策略、request 组装、成功态迁移
• editor/src/Viewport/ViewportHostService.h
  • 保留真正的 orchestration、scene view camera、post pass 组装与 clear 执行

这意味着 viewport host 已经不再是“一个面板私有的大杂烩类”，而是一个有明确宿主边界的 editor 侧接入层。

3. 现阶段测试闭环已经补上

当前 editor 侧已经有明确的宿主层单测覆盖：

• tests/editor/test_viewport_host_surface_utils.cpp
• tests/editor/test_viewport_render_targets.cpp
• tests/editor/test_viewport_object_id_picker.cpp
• tests/editor/test_viewport_render_flow_utils.cpp

本轮收口完成后，editor_tests 已覆盖 viewport host 中最容易回归的纯策略与资源管理逻辑。

为什么到这里应当停止继续拆

当前 editor/src/Viewport/ViewportHostService.h 剩下的主要内容，是以下几类“真正属于宿主编排”的职责：

• scene view camera 的创建与驱动
• focus / orientation axis 等 editor 专属视图控制
• scene view post pass 的装配
• scene/game viewport 的 render dispatch
• clear 执行

这些逻辑如果继续硬拆，很容易为了“文件更小”而把真正依赖 editor 运行时状态的 orchestration 人为打散，收益已经明显下降。

所以这一阶段的明确结论是：

• ViewportHostService 继续保持为宿主编排入口是合理的
• 不再以“继续拆文件”为本阶段目标
• 下一阶段应把重点转移到 renderer 本身的演进，而不是继续挤压 editor host

本阶段的结束标准

这一阶段以以下标准视为完成：

1. editor_tests 全部通过
2. XCEditor 能正常编译
3. viewport host 的主要纯逻辑都有独立单测
4. ViewportHostService 不再继续承载资源创建、object id 读取、失败策略等细碎职责
5. 明确哪些问题属于后续 renderer 阶段，而不是继续留在当前阶段消耗

明确不属于本阶段的内容

以下内容不再计入“editor viewport 宿主渲染收口”阶段：

• GPU object id 正式拾取方案
• renderer 内部通用多 pass / render graph 体系
• 更正式的 editor outline 方案升级
• gizmo 全量产品化
• 光照、阴影、后处理
• runtime 渲染管线的完整 SRP 式抽象

这些内容应进入 renderer 后续阶段，而不是继续塞回当前 viewport host 收口任务。

下一阶段建议

下一阶段主线应转为：

1. renderer 能力继续上移

把目前 editor 层为了接通 viewport 而保留的一些临时职责，逐步让 renderer 吸收为正式能力，例如：

• 多 pass 组织能力
• 正式的 object id / editor helper pass 接口
• editor 与 runtime 共享的 camera render path

2. editor 只消费 renderer 提供的正式输出

editor viewport 后续应更多扮演：

• render target 宿主
• 输入转发
• overlay / gizmo 宿主
• editor 专属交互入口

而不是继续承载 renderer 内部演进本体。

阶段性结论

这一阶段现在可以正式收口：

• editor viewport 已经从“空面板”进入“真实宿主层”
• renderer 与 RHI 已经能稳定把离屏结果送进 editor
• viewport host 的边界已经明确
• 后续不应继续在本阶段内部无限拆分，而应切换到 renderer 下一阶段