# MetaCore 场景编辑与层级工作流设计 生成时间：2026-03-28 状态：草案 范围：M3 场景编辑、材质与光照工作流 ## 目的 这份文档用于明确 MetaCore 第一阶段的场景编辑与层级工作流应该怎么设计。 目标不是做一个“能显示对象树”的面板，而是做出一套真正能支撑工业数字孪生项目内容生产的基础编辑工作流。 它要解决的问题包括： - 对象在场景中怎么组织 - 父子级怎么工作 - 拖拽重挂接怎么工作 - 多选、复制、删除怎么工作 - 模型资源拖入场景后生成什么 - Gizmo 和 Transform 编辑如何与层级系统配合 ## 结论先说 MetaCore 第一阶段的场景编辑工作流，应该明确对标： **Unity / UE 风格的“Hierarchy + Scene View + Inspector”最小生产力闭环** 它的核心不是功能多，而是这条链必须顺： ```text 资源进入项目 -> 拖入场景 -> 生成对象树 -> 在 Hierarchy 中组织 -> 在 Scene View 中摆放 -> 在 Inspector 中调整 -> 保存并重开仍然一致 ``` 如果这条链不成立，前面的模型导入、材质系统和后面的 RuntimeData 都很难真正落地。 ## 当前代码基础 当前代码里已经具备一些可复用的基础能力： - 创建对象 - 查找对象 - 获取根对象和子对象 - 构建层级前序遍历 - 删除对象及其子树 - 复制对象及其子树 - 批量重挂接对象 - 场景快照、撤销重做基础 这说明 MetaCore 已经不是从零开始，而是已经有了场景数据层基础。 当前更缺的是： - 把这些能力组织成清晰的编辑工作流 - 明确对象、资源、层级三者的关系 - 明确模型拖入场景如何生成对象树 - 明确 Gizmo、多选、重挂接、Inspector 的交互约定 ## 第一阶段设计目标 第一阶段场景编辑工作流要满足： - 支撑工业场景对象组织 - 支撑模型导入后的对象树实例化 - 支撑 Transform 基础编辑 - 支撑对象复制、删除、重命名、重挂接 - 支撑对象与资源分离 - 支撑 Scene 保存/重开一致性 - 为 Prefab 和后续 RuntimeData 留出空间 ## 核心概念 ### 1. Scene Scene 是对象实例的容器，负责： - 保存对象树 - 保存对象组件数据 - 保存对象之间的父子关系 Scene 不直接保存资源本体，只保存对资源的引用。 ### 2. GameObject GameObject 是场景中的实例节点，负责： - 名称 - 唯一 ID - 父子关系 - 组件集合 ### 3. Resource 资源是被场景对象引用的外部资产，例如： - Mesh Asset - Material Asset - Texture Asset - Prefab Asset 资源不是场景节点本身。 ### 4. Hierarchy Hierarchy 是 Scene 对象树的编辑视图，不是单独的一份数据。 它负责表达： - 根对象 - 子对象 - 展开折叠 - 选择状态 - 拖拽重挂接 ## 第一阶段工作流总图 ```mermaid flowchart LR A["Project 面板"] --> B["将模型/Prefab 拖入场景"] B --> C["根据资源生成 GameObject 树"] C --> D["Hierarchy 中显示对象树"] D --> E["Scene View 中摆放与选择"] E --> F["Inspector 中编辑 Transform/组件/资源引用"] F --> G["保存 Scene"] G --> H["重新打开 Scene 后结果一致"] ``` ## 对象创建规则 第一阶段应明确三类创建方式： ### 1. 空对象创建 用于： - 逻辑分组 - 组织层级 - 作为父节点容器 ### 2. 内置对象创建 用于： - Cube - 未来的 Plane、Sphere 等原型几何 这有利于： - 快速搭测试场景 - 不依赖导入资源也能编辑布局 ### 3. 资源实例创建 用于： - 模型资源拖入场景 - Prefab 拖入场景 这是第一阶段真正需要打通的重点。 ## 模型资源拖入场景规则 这是场景编辑工作流里最关键的新增点之一。 ### 规则 1：拖入模型资源时，生成对象树而不是单一节点 如果导入的模型保留了节点层级，那么拖入场景后应根据模型节点描述生成对应的 `GameObject` 树。 不要把整个模型强行压成一个单节点对象。 ### 规则 2：每个节点保留局部变换 这样： - 装配关系 - 部件位置 - 工业模型层级 才能正确进入 Scene。 ### 规则 3：带 Mesh 的节点生成 MeshRenderer 节点如果引用了某个 `Mesh Asset`，则实例化对象应带： - `Transform` - `MeshRenderer` 并正确引用： - `MeshAssetGuid` - `MaterialAssetGuids` ### 规则 4：根节点命名应可读 拖入后根对象名称应优先来自： - 模型名 - 或根节点名 避免出现一堆无意义自动名。 ## Hierarchy 面板设计 ### 第一阶段必须支持 - 树状显示对象 - 展开 / 折叠 - 单选 - 多选 - 当前激活对象高亮 - 重命名 - 拖拽重挂接 - 删除 - 复制 ### 第一阶段推荐支持 - 搜索过滤 - 根节点快速创建 - 右键菜单 ### 第一阶段可以后置 - 复杂标签系统 - 场景分层/层管理器 - 多场景同时编辑 ## 选择模型 第一阶段建议采用： - `Hierarchy` 和 `Scene View` 共享同一选择状态 - `Inspector` 始终展示当前激活对象 - 多选时 Inspector 支持基础公共字段编辑 ### 多选第一阶段建议支持的字段 - `Visible` - `Transform` 的基础值 - 灯光颜色 / 强度 - MeshRenderer 的简单开关 复杂差异编辑可以后置。 ## 重挂接规则 第一阶段必须明确重挂接时的行为。 ### 规则 1：不能挂到自己的子树下面 这会导致层级环。 ### 规则 2：支持保留世界变换 这是最符合编辑器习惯的行为。 建议第一阶段默认： - Hierarchy 拖拽重挂接时保留世界变换 ### 规则 3：多对象重挂接应视为一个原子编辑动作 这样撤销重做才合理。 ## 复制与删除规则 ### 删除 第一阶段应明确： - 删除对象时默认删除其整个子树 - 多选删除时要去重，避免重复删除子节点 ### 复制 第一阶段应明确： - 复制对象时复制整个子树 - 新对象保留组件结构 - 新对象保留资源引用 - 新对象生成新的对象 ID 这对工业设备、告警组件、UI 锚点等复用很重要。 ## Transform 与 Gizmo 工作流 这一部分是 Scene 编辑的生产力核心。 ### 第一阶段必须支持 - Move - Rotate - Scale - Position / Rotation / Scale 在 Inspector 中可编辑 - Scene View 中基础 Gizmo 操作 ### 第一阶段推荐支持 - Local / World 切换 - Pivot / Center 行为预留 - 聚焦当前对象 ### 与层级的关系 Transform 编辑必须基于对象的父子层级来解释局部变换。 也就是说： - Scene 中保存的是局部变换 - 世界变换在运行时和编辑计算时推导 不要把世界变换直接存回 Scene 作为主数据。 ## Inspector 规则 第一阶段 Inspector 至少应清晰分层： ### 对象级 - 名称 - 启用状态（后续可加） - 父对象信息 ### Transform - Position - Rotation - Scale ### 组件级 - MeshRenderer - Light - Camera - 后续其他组件 Inspector 要做的是“编辑当前对象”，不要把资源浏览、运行时诊断、复杂项目管理都混进来。 ## 保存与恢复规则 第一阶段必须保证： - Hierarchy 结构可保存 - 父子关系可恢复 - 组件数据可恢复 - 资源引用可恢复 - 重新打开 Scene 后结构不乱 如果导入模型拖入场景后保存重开不能保持一致，那整个工作流就是不稳定的。 ## 与 Prefab 的关系 第一阶段场景工作流必须考虑后续 Prefab 复用。 建议规则： - 场景中的对象树可以被抽成 Prefab - Prefab 实例进入 Scene 后仍表现为普通对象树 - 层级结构和资源引用规则保持一致 这样设备、阀门、泵、面板、指示灯这类重复对象才能真正规模化复用。 ## 与 RuntimeData 的关系 RuntimeData 不应主导场景编辑结构。 更合理的关系是： - Scene 负责对象树和组件结构 - RuntimeData 只负责在运行时驱动这些对象的显示状态或组件参数 也就是说： - 先有稳定场景工作流 - 再把 RuntimeData 挂进去 这才符合引擎基础优先的路线。 ## 推荐实现顺序 建议按下面顺序推进： 1. 固定 Hierarchy 数据和交互规则 2. 固定选择模型 3. 固定复制、删除、重挂接规则 4. 打通 Transform Inspector 与基础 Gizmo 5. 打通模型资源拖入场景生成对象树 6. 验证 Scene 保存/重开一致性 7. 再增强多选、搜索、右键菜单等体验 ## 第一阶段 Definition of Done 下面这些成立时，才能认为第一阶段场景编辑工作流真正可用： - 用户可以创建空对象和内置对象 - 用户可以将模型资源拖入场景并生成对象树 - Hierarchy 能正确显示和编辑对象树 - 支持多选、复制、删除、重命名、重挂接 - Scene View 可选择和操作对象 - Inspector 可编辑 Transform 和基础组件 - Scene 保存并重开后结果一致 ## 最终建议 第一阶段最重要的不是把编辑器做得花，而是把工作流做顺。 所以最合理的方向是： **把 Scene、Hierarchy、Scene View、Inspector 串成一条稳定的对象编辑链，让导入进来的模型真正能被组织、摆放、调整和保存。** 这一步一旦做稳，MetaCore 才真正开始像一个能开发工业数字孪生项目的引擎，而不是一个只有零散功能的工具集合。