XCEngine/docs/used/Editor模块_宿主渲染与EngineRHI未统一导致Viewport纹理无法接入3.28.md

Editor模块 宿主渲染与EngineRHI未统一导致Viewport纹理无法接入

1. 问题定义

当前 editor 的窗口宿主渲染仍然是一套独立的原生 D3D12 路径：

• editor/src/Application.h
• editor/src/Application.cpp
• editor/src/Platform/D3D12WindowRenderer.h

这套路径只负责：

• 创建 Win32 窗口交换链
• 创建独立的 ID3D12Device / ID3D12CommandQueue
• 渲染 ImGui 主界面

而当前引擎的 RHI / Renderer 则是另一套独立设备与上下文体系。

这意味着后续即使 Renderer 能把 SceneView/GameView 渲染到离屏目标，editor 侧也没有稳定的统一设备桥接层把那张纹理安全地贴到 ImGui。

---

2. 当前现状

当前 Application::InitializeWindowRenderer() 直接创建原生 D3D12 宿主：

• editor 只知道 Platform::D3D12WindowRenderer
• editor 并不持有 RHIDevice / RenderContext / RenderSurface
• SceneViewPanel / GameViewPanel 也没有可复用的 viewport host 对象

结果是：

• editor 主界面渲染和引擎 Renderer 渲染仍然分裂
• 未来 viewport 要么走不通
• 要么被迫写一层高风险的 D3D12 私有纹理互拷/句柄桥接
• 要么反向污染 Renderer，使其去适配 editor 私有宿主

---

3. 为什么这是重大缺陷

这不是“面板里还没把图显示出来”的小缺口，而是 viewport 接入的根部边界问题。

如果不先统一宿主层，后面很容易走成错误路线：

• Editor 继续维护一套私有 D3D12 设备
• Renderer 再维护一套引擎 RHI 设备
• SceneView 和 GameView 为了显示纹理被迫做后端专用互操作
• Vulkan / OpenGL 路径在 editor 中天然失去接入可能

这会直接破坏：

• RHI 抽象边界
• Renderer 的后端无关性
• 后续 editor viewport 与 runtime 共用同一渲染链路的目标

---

4. 建议方案

正确方向应该是：

1. editor 宿主层只保留“窗口 + ImGui 宿主”职责
2. viewport 输出统一来自引擎 Renderer 的 RenderSurface
3. editor 增加专门的 viewport bridge / host 层，而不是把渲染实现塞进 panel
4. 该 bridge 层需要明确处理：
   • 使用哪个 RHI backend
   • 如何创建离屏 color/depth 目标
   • 如何把离屏结果暴露为 ImGui 可显示纹理
   • resize 生命周期
   • device/context 所有权

建议不要继续扩张 D3D12WindowRenderer 的职责。

它可以继续作为 editor 主窗口 UI 宿主，但不应成为 viewport 真实渲染实现本体。

---

5. 验收标准

完成后至少应满足：

1. editor 可以不依赖私有 D3D12 纹理路径来显示 viewport
2. SceneView 和 GameView 都走统一的 viewport host 接口
3. viewport 输出来自引擎 RenderSurface
4. editor 不需要因为切换 OpenGL / D3D12 / Vulkan 而重写面板逻辑
5. Renderer 不需要反向依赖 editor 平台实现

---

6. 优先级

高。

在开始正式做 Scene/Game Viewport 之前必须先收敛这个边界，否则后面的接入实现会天然带着架构债。