gengjiayuan/MetaCore
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
c8ba59f07a
MetaCore/docs/designs/metacore-engine-foundation-priority.md

7.0 KiB
Raw Blame History

MetaCore 引擎基础能力优先级

生成时间：2026-03-28
状态：草案
读者：产品、架构、引擎、编辑器、交付

目的

这份文档用于纠正当前第一阶段的开发顺序。

核心结论很简单：

MetaCore 第一阶段应该先成为一个可用于构建工业三维应用的可用引擎和编辑器，然后再叠加数字孪生特有的运行时数据能力。

运行时数据很重要，但它不是引擎主干。

执行摘要

当前项目在 RuntimeData 方向已经有了不少有效进展：

  • 独立的运行时数据模块
  • 二进制运行时配置
  • 多种适配器
  • 编辑器侧 binding 配置
  • Player 侧数据分发

这些工作都应该保留。

但它不应该继续定义第一阶段的关键路径。

如果 MetaCore 的目标是“像 Unity / Unreal 一样，用于开发工业数字孪生项目的引擎”，那第一阶段的正确顺序应该是：

  1. 项目与内容工作流
  2. 资源与模型导入
  3. 场景编辑与层级
  4. 材质与光照
  5. 场景持久化
  6. UI 工作流
  7. 打包与运行时
  8. RuntimeData 集成

为什么顺序这么重要

数字孪生团队不会先从把一个点位绑定到对象开始。

他们会先做这些事：

  • 创建项目
  • 导入模型
  • 组织场景层级
  • 调整变换
  • 指派材质
  • 设置灯光与相机
  • 搭界面
  • 保存场景
  • 打包一个可运行客户端

只有这些步骤成立之后，运行时数据才真正有价值。

如果引擎不能顺畅支撑这些基础步骤，那 RuntimeData 只能驱动一个薄 demo，而不是可交付流程。

专业判断

从产品和工程两个视角看，第一阶段的正确定义应该是：

MetaCore 第一阶段是一个具备项目、资源、场景、材质、光照、UI、持久化和打包工作流的工业级引擎/编辑器底座，并在其上提供第一版 RuntimeData 子系统用于数字孪生集成。

它不是：

  • 一个数据驱动 demo 壳
  • 一个完整数字孪生平台
  • 一个完整 VR 训练平台

第一阶段的正确开发顺序

Phase 1A：引擎生产力工作流

这是新的主干。

必须包含：

  • 项目创建与打开
  • 启动场景行为
  • 资源导入与资源数据库
  • 模型导入与层级保留
  • 场景层级编辑
  • Transform 编辑与 Gizmo
  • 材质创建、复用与指派
  • 基础光照
  • 场景保存/打开
  • UI 基础编辑
  • 打包与独立运行时

Phase 1B：数字孪生使能

这部分建立在引擎工作流之上。

必须包含：

  • 运行时数据源抽象
  • 数据点模型
  • 场景 binding 模型
  • 运行时诊断
  • 一个或多个 live adapter

优先级模型

P0：现在必须立刻抬高优先级

这些才是真正的引擎阻塞项。

  • 项目系统
  • 模型导入
  • 场景层级编辑
  • Transform 工具与 Gizmo
  • 材质系统
  • 光照基础
  • 场景保存/打开
  • 打包与独立运行时

P1：紧随 P0

  • Project 面板与资源管理
  • UI 基础编辑
  • prefab 强化
  • 相机与视口工作流
  • 资源刷新与重新导入稳定性
  • 运行时诊断可见性

P2：重要，但应晚于引擎底座

  • RuntimeData 集成
  • 数字孪生样板模板
  • 更多 live adapter
  • 行业化运行时组件

P3：后续扩展

  • VR/XR 工作流
  • 浏览器嵌入产品化
  • AI 辅助工具
  • 仿真编排

首批推荐能力集合

1. 项目系统

必须支持：

  • 创建/打开项目
  • 稳定的项目目录布局
  • 启动场景
  • 项目描述文件持久化

为什么重要：

  • 这是所有后续工作流的入口

2. 模型导入

必须支持：

  • 一等支持 glTF/.glb
  • 第二阶段支持 FBX
  • 可选支持 OBJ

建议：

  • 把 glTF/.glb 做成第一优先的生产级导入器

原因：

  • 现代、清晰、适合可控工具链
  • 比 FBX-first 路线更可预测
  • 足够覆盖早期很多工业可视化场景

3. 场景编辑与层级

必须支持：

  • 创建/删除/复制
  • 重命名
  • 父子级
  • 拖拽重挂接
  • 多选
  • 稳定的选择行为

4. Transform 工具

必须支持：

  • 移动
  • 旋转
  • 缩放
  • 本地/世界坐标模式
  • 基础吸附

没有这套东西，编辑器就谈不上生产可用。

5. 材质系统

必须支持：

  • 材质资源
  • 基础色
  • 纹理槽
  • 基础 PBR 参数
  • 材质复用

6. 光照

必须支持：

  • Directional Light
  • Point Light
  • Spot Light
  • 稳定的场景照明
  • 条件允许时补基础阴影

7. 场景持久化

必须支持：

  • 新建场景
  • 保存
  • 另存
  • 重新打开
  • 启动场景加载

对这个仓库来说，二进制 package 持久化是正确方向。

8. UI 工作流

必须支持：

  • 静态面板
  • 文本
  • 图片
  • 按钮
  • 基础布局
  • UI 资源引用

这是数字孪生项目的硬需求。

9. 打包

必须支持：

  • 独立 Player
  • 启动场景接管
  • 项目内容打包带出
  • clean machine 运行验证

当前思维模型里的遗漏项

下面这些点很容易被低估，但它们都属于核心引擎工作。

资源管理

导入远远不够。

还需要：

  • Project 面板
  • 元数据可见
  • 重命名/移动行为
  • 重新导入行为
  • package 引用稳定性

视口工作流

一个 3D 编辑器必须具备：

  • 稳定的 orbit/fly 导航
  • 聚焦选中对象
  • 明确的相机行为
  • 编辑器视角和运行时视角分离

Prefab/模板工作流

工业场景会重复大量对象：

  • 阀门
  • 罐体
  • 指示器
  • 告警灯
  • 设备

没有 prefab/template 复用，内容生产效率会很差。

导入归一化

一个真正可用的导入器最终必须处理：

  • 坐标系归一化
  • 缩放归一化
  • 网格/材质映射
  • 层级保留
  • 重新导入一致性

诊断与错误可见性

交付团队需要清晰的失败面：

  • 导入失败
  • 资源缺失
  • 场景无法读取
  • runtime config 不匹配
  • binding 失败

扩展点

即使 VR 或脚本系统还没完成，引擎也应该先预留：

  • 应用模块挂点
  • 运行时组件扩展点
  • 导入器扩展点
  • adapter 扩展点

RuntimeData 现有工作哪些仍然有效

当前已经做的 RuntimeData 工作不是错误。

应该保留，但重新归类：

  • 它不是第一阶段主干
  • 它是 Phase 1B 子系统
  • 它在一些方向上已经超前于部分基础层

这其实是有价值的：

  • 它证明了引擎已经能承载一个行业化子系统
  • 它提前打通了未来的数据路径
  • 一旦内容工作流更稳，它就能直接复用

修正后的里程碑形态

旧的里程碑顺序让 RuntimeData 过早主导节奏。

修正后的顺序应该是：

M1 引擎壳与项目循环
  -> M2 资源与模型导入循环
    -> M3 场景编辑、材质与光照工作流
      -> M4 UI、持久化与打包循环
        -> M5 面向数字孪生的 RuntimeData 集成
          -> M6 硬化与未来预留

最终建议

MetaCore 应该先被做成：

一个可用的工业三维引擎/编辑器

然后再做成：

一个具备数字孪生能力的引擎

顺序不能反。

如果不强制执行这个顺序，项目会继续滑向“行业功能优先”，而不是“引擎基础能力优先”。