308 lines
6.1 KiB
Markdown
308 lines
6.1 KiB
Markdown
# MetaCore 第一阶段实施计划
|
||
|
||
生成时间：2026-03-27
|
||
状态：草案
|
||
范围：第一阶段执行
|
||
|
||
## 目的
|
||
|
||
这份文档把第一阶段范围翻译成实施路线图。
|
||
|
||
它要回答：
|
||
|
||
- 先做什么
|
||
- 谁依赖谁
|
||
- 每个里程碑在证明什么
|
||
- 当前真正应该推进哪一段
|
||
|
||
## 里程碑总览
|
||
|
||
第一阶段应拆成 6 个里程碑，并把引擎生产力工作流排在 RuntimeData 前面。
|
||
|
||
```text
|
||
M1 引擎壳与项目循环
|
||
-> M2 资源与模型导入循环
|
||
-> M3 场景编辑、材质与光照工作流
|
||
-> M4 UI、持久化与打包循环
|
||
-> M5 面向数字孪生的 RuntimeData 集成
|
||
-> M6 引擎硬化与未来预留
|
||
```
|
||
|
||
## M1 引擎壳与项目循环
|
||
|
||
### 目标
|
||
|
||
让 MetaCore 成为一个具备稳定项目行为的引擎壳。
|
||
|
||
### 交付物
|
||
|
||
- 稳定的 Windows 应用主循环
|
||
- 稳定的平台层
|
||
- 项目打开/创建行为
|
||
- 启动场景行为
|
||
- 独立 Player 执行能力
|
||
|
||
### 关键工作流
|
||
|
||
- 应用生命周期
|
||
- 模块与服务启动
|
||
- 项目描述文件处理
|
||
- 视口渲染稳定性
|
||
- 编辑器基线工作流与项目引导
|
||
|
||
### 完成标准
|
||
|
||
- 项目能稳定打开
|
||
- 启动场景能被解析
|
||
- 运行时能加载并渲染启动场景
|
||
|
||
## M2 资源与模型导入循环
|
||
|
||
### 目标
|
||
|
||
让 MetaCore 从“只有场景原型”变成“能围绕资源工作的工具”。
|
||
|
||
### 交付物
|
||
|
||
- 资源元数据生成
|
||
- 资源数据库稳定
|
||
- 导入流程稳定
|
||
- 一等支持的模型导入工作流
|
||
- package 流程稳定
|
||
- 重新导入与资源浏览基础
|
||
|
||
### 关键工作流
|
||
|
||
- 资源元数据与 package 格式
|
||
- 导入流水线
|
||
- 模型格式支持
|
||
- Project 面板工作流
|
||
- prefab 基础
|
||
|
||
### 完成标准
|
||
|
||
- 导入的资源稳定出现
|
||
- 导入的模型能在场景中使用
|
||
- 场景和资源在重载后仍然有效
|
||
|
||
## M3 场景编辑、材质与光照工作流
|
||
|
||
### 目标
|
||
|
||
让 MetaCore 真正可用于内容搭建。
|
||
|
||
### 交付物
|
||
|
||
- 稳定的层级编辑
|
||
- Transform Gizmo
|
||
- 材质工作流
|
||
- 光照工作流
|
||
- 可用的视口编辑体验
|
||
|
||
### 关键工作流
|
||
|
||
- 层级行为
|
||
- 多选和操作
|
||
- Transform 工具
|
||
- 材质资源与材质指派
|
||
- 灯光编辑
|
||
|
||
### 完成标准
|
||
|
||
- 可以基于导入资源搭一个场景
|
||
- 材质和光照可以稳定编辑
|
||
- 编辑器内容生产不再依赖硬编码 demo 对象
|
||
|
||
## M4 UI、持久化与打包循环
|
||
|
||
### 目标
|
||
|
||
让 MetaCore 作为项目工具具备交付能力。
|
||
|
||
### 交付物
|
||
|
||
- UI 基础编辑
|
||
- 场景保存/打开成熟化
|
||
- Windows 打包验证
|
||
- 项目级 pilot 打包流程
|
||
|
||
### 关键工作流
|
||
|
||
- UI 资源与 UI 运行时
|
||
- 二进制场景持久化
|
||
- 启动场景打包
|
||
- clean machine 验证
|
||
|
||
### 完成标准
|
||
|
||
- 开发者能构建并打包一个小型工业三维可视化客户端
|
||
- 打包后的运行时在编辑器外表现稳定
|
||
|
||
## M5 面向数字孪生的 RuntimeData 集成
|
||
|
||
### 目标
|
||
|
||
在引擎基础工作流之上叠加数字孪生所需的 RuntimeData 能力。
|
||
|
||
### 交付物
|
||
|
||
- 独立的 RuntimeData 模块
|
||
- source / point / binding 模型
|
||
- runtime config 持久化
|
||
- live adapter 支持
|
||
- binding 配置工作流
|
||
- runtime diagnostics
|
||
|
||
### 关键工作流
|
||
|
||
- RuntimeData 架构
|
||
- adapter 与 binding 模型
|
||
- 运行时分发与故障处理
|
||
- 编辑器侧配置
|
||
- 数字孪生样板工程
|
||
|
||
### 完成标准
|
||
|
||
- 打包后的运行时能把外部数据应用到场景目标
|
||
- 运行时故障可见且不会导致崩溃
|
||
- 引擎能支撑一个小型数字孪生项目
|
||
|
||
## M6 引擎硬化与未来预留
|
||
|
||
### 目标
|
||
|
||
把 MetaCore 强化成一个可长期演进的引擎底座。
|
||
|
||
### 交付物
|
||
|
||
- 更清晰的 Runtime / Editor 分离
|
||
- 更强的诊断能力
|
||
- 更干净的子系统边界
|
||
- XR 与 B/S 的未来预留在代码结构中落地
|
||
|
||
### 关键工作流
|
||
|
||
- 模块边界清理
|
||
- 诊断与健康可见性
|
||
- 未来扩展接口
|
||
- 样板与测试扩充
|
||
|
||
### 完成标准
|
||
|
||
- 第二阶段工作不需要推翻第一阶段架构
|
||
|
||
## 任务树
|
||
|
||
### A. 引擎基础
|
||
|
||
- A1 应用生命周期
|
||
- A2 平台服务
|
||
- A3 日志
|
||
- A4 模块启动
|
||
|
||
### B. 场景与对象系统
|
||
|
||
- B1 场景结构
|
||
- B2 GameObject 层级
|
||
- B3 组件状态
|
||
- B4 持久化
|
||
- B5 prefab 基础
|
||
|
||
### C. 渲染与运行时
|
||
|
||
- C1 渲染桥
|
||
- C2 场景视口
|
||
- C3 运行时视口
|
||
- C4 相机控制
|
||
- C5 光照基础
|
||
|
||
### D. 项目与资源循环
|
||
|
||
- D1 项目描述文件
|
||
- D2 资源元数据
|
||
- D3 资源数据库
|
||
- D4 导入流程
|
||
- D5 package 流程
|
||
- D6 cook 流程
|
||
|
||
### E. 编辑器
|
||
|
||
- E1 Hierarchy 面板
|
||
- E2 Scene 视图
|
||
- E3 Inspector
|
||
- E4 Project 面板
|
||
- E5 Console
|
||
- E6 Undo / Redo
|
||
|
||
### F. UI 与交付
|
||
|
||
- F1 UI 资源与 UI 运行时
|
||
- F2 场景持久化
|
||
- F3 打包
|
||
- F4 clean-machine 验证
|
||
|
||
### G. RuntimeData
|
||
|
||
- G1 RuntimeData 模块
|
||
- G2 RuntimeData 类型系统
|
||
- G3 source 与 binding 文档
|
||
- G4 adapter 接口
|
||
- G5 dispatcher
|
||
- G6 live adapter
|
||
- G7 binding 编辑
|
||
- G8 诊断与 stale 处理
|
||
|
||
### H. 未来预留
|
||
|
||
- H1 XR 扩展边界
|
||
- H2 B/S 扩展边界
|
||
- H3 子系统清理
|
||
|
||
## 修正后的实施重点
|
||
|
||
旧建议过早把 RuntimeData 放在主线中央。
|
||
|
||
修正后的顺序应该是：
|
||
|
||
1. 先做 M1 和 M2
|
||
2. 再做 M3
|
||
3. 再做 M4
|
||
4. 最后再让 M5 成为主导
|
||
|
||
RuntimeData 仍然重要，但它现在应该被视为 Phase 1B 子系统，而不是第一阶段最先主导实现节奏的模块。
|
||
|
||
## 当前关键路径
|
||
|
||
当前关键路径应该是：
|
||
|
||
```text
|
||
项目循环
|
||
-> 资源与模型导入
|
||
-> 层级与 Transform 工作流
|
||
-> 材质与光照工作流
|
||
-> 场景保存/打开
|
||
-> UI 基础
|
||
-> 打包
|
||
-> RuntimeData 集成
|
||
```
|
||
|
||
如果这条路径被过早的行业子系统实现打断，MetaCore 会继续表现得像一个专用 demo，而不是一个可用于开发项目的引擎工具。
|
||
|
||
## 当前执行焦点的完成标准
|
||
|
||
当前执行焦点完成时，应满足：
|
||
|
||
- 项目可以稳定打开并引导
|
||
- 导入的模型资源可以进入场景
|
||
- 层级编辑和 Transform 操作稳定
|
||
- 材质和光照可以重复性编辑
|
||
- 场景可以保存、重开并打包
|
||
|
||
只有在这些点成立之后，RuntimeData 才应该重新成为第一阶段主导任务。
|
||
|
||
## 立即下一步
|
||
|
||
从 M1 和 M2 开始推进。
|
||
|
||
在引擎内容工作流足够强之前，不要继续优先扩 adapter、工业协议或更多 RuntimeData 专属工具。
|