gengjiayuan/MetaCore
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
master
MetaCore/docs/designs/metacore-phase1-implementation-plan.md

6.1 KiB
Raw Permalink Blame History

MetaCore 第一阶段实施计划

生成时间：2026-03-27
状态：草案
范围：第一阶段执行

目的

这份文档把第一阶段范围翻译成实施路线图。

它要回答：

  • 先做什么
  • 谁依赖谁
  • 每个里程碑在证明什么
  • 当前真正应该推进哪一段

里程碑总览

第一阶段应拆成 6 个里程碑，并把引擎生产力工作流排在 RuntimeData 前面。

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 子系统，而不是第一阶段最先主导实现节奏的模块。

当前关键路径

当前关键路径应该是：

项目循环
  -> 资源与模型导入
    -> 层级与 Transform 工作流
      -> 材质与光照工作流
        -> 场景保存/打开
          -> UI 基础
            -> 打包
              -> RuntimeData 集成

如果这条路径被过早的行业子系统实现打断，MetaCore 会继续表现得像一个专用 demo，而不是一个可用于开发项目的引擎工具。

当前执行焦点的完成标准

当前执行焦点完成时，应满足：

  • 项目可以稳定打开并引导
  • 导入的模型资源可以进入场景
  • 层级编辑和 Transform 操作稳定
  • 材质和光照可以重复性编辑
  • 场景可以保存、重开并打包

只有在这些点成立之后，RuntimeData 才应该重新成为第一阶段主导任务。

立即下一步

从 M1 和 M2 开始推进。

在引擎内容工作流足够强之前，不要继续优先扩 adapter、工业协议或更多 RuntimeData 专属工具。