XCEngine/docs/used/Renderer模块_EditorViewport缺少RenderSurface接入层3.27.md

Renderer模块 EditorViewport缺少RenderSurface接入层

1. 问题定义

当前 editor 已经有：

• GameViewPanel
• SceneViewPanel

但二者目前仍然是空面板，尚未形成真正的 viewport 渲染宿主。

这意味着 Renderer 即使在 runtime 侧建立起来，editor 侧也还没有标准方式去承接：

• 离屏 color/depth 输出
• viewport resize
• 渲染结果贴到 ImGui 面板

---

2. 当前现状

当前 GameViewPanel::Render() 与 SceneViewPanel::Render() 仅创建面板窗口，本身没有：

• 离屏渲染目标
• 渲染尺寸管理
• RHI / Renderer 级渲染输出对象
• 纹理到 ImGui 的桥接

也就是说，editor 当前只有“面板外壳”，还没有“渲染宿主层”。

---

3. 为什么这不应该反向污染 Renderer 设计

这个问题很容易走偏成下面这种错误路线：

• 先把 renderer 直接写进 editor 面板逻辑
• SceneView 一套渲染逻辑
• GameView 一套渲染逻辑
• runtime 又一套渲染逻辑

这会导致：

• 渲染逻辑重复
• editor 与 runtime 耦合
• 后续 C# SRP 难以统一接管

因此正确思路不是“先让面板自己画”，而是：

1. Renderer 模块先支持统一的 RenderSurface
2. editor viewport 只作为 RenderSurface 的宿主与展示层

---

4. 建议方案

4.1 先在 Renderer 模块建立 RenderSurface

RenderSurface 应统一描述：

• swapchain 输出
• 离屏 color / depth 目标
• viewport 尺寸
• resize 行为

4.2 editor 侧建立 viewport host 层

editor 侧后续应新增一层专门承接：

• 面板尺寸变化
• 请求 Renderer 重建或 resize RenderSurface
• 把结果纹理显示到 ImGui

而不是把渲染实现直接塞进面板类。

4.3 SceneView 与 GameView 应共享同一套 Renderer 输出机制

区别只在于：

• GameView 使用 runtime camera
• SceneView 使用 editor 自有 camera / gizmo / overlay

但底层渲染输出机制应一致。

---

5. 与未来 Unity 风格演进的关系

未来如果要做接近 Unity 的 editor 与 SRP 体系，这一层非常关键。

因为 Unity 的：

• Game 视图
• Scene 视图
• Camera 预览

本质上都不是复制多套渲染器，而是在同一渲染体系上挂不同宿主与附加绘制。

XCEngine 也应遵循同样思路。

---

6. 验收标准

完成后至少应满足：

1. Renderer 能输出到离屏 RenderSurface
2. GameView 能显示 renderer 的离屏结果
3. SceneView 能显示 renderer 的离屏结果
4. viewport resize 不需要复制新的渲染逻辑
5. runtime 与 editor 共用同一套渲染宿主接口

---

7. 优先级

中到高。

它不是 Renderer v0 的第一步实现内容，但必须在 renderer 基础链路稳定后尽快接上，否则 editor 渲染体系会被迫走临时方案。