803 lines
16 KiB
Markdown
803 lines
16 KiB
Markdown
# MetaCore 引擎功能清单与能力基线
|
||
|
||
生成时间：2026-04-01
|
||
状态：草案
|
||
读者：产品、架构、引擎、编辑器、渲染、工具链
|
||
|
||
## 目的
|
||
|
||
这份文档用于明确 MetaCore 的功能清单应该按“引擎能力”定义，而不是按“数字孪生方案能力”定义。
|
||
|
||
MetaCore 的定位是：
|
||
|
||
- 一个通用三维引擎与编辑器平台
|
||
- 第一阶段先完成可支撑数字孪生项目开发的能力闭环
|
||
- 但所有优先建设的能力都应尽量沉淀为通用引擎能力，而不是行业特化逻辑
|
||
|
||
这份文档回答三个问题：
|
||
|
||
1. MetaCore 作为引擎，功能清单应该怎么分层
|
||
2. 当前仓库已经具备了哪些能力
|
||
3. 哪些能力是第一阶段最应该优先补齐的
|
||
|
||
## 与其他文档的关系
|
||
|
||
这份文档是“引擎能力基线”，与其他文档分工如下：
|
||
|
||
- [metacore-product-plan.md](D:/MetaCore/docs/designs/metacore-product-plan.md)：定义产品定位和商业切口
|
||
- [metacore-phase1-scope.md](D:/MetaCore/docs/designs/metacore-phase1-scope.md)：定义第一阶段交付边界
|
||
- [metacore-engine-foundation-priority.md](D:/MetaCore/docs/designs/metacore-engine-foundation-priority.md)：定义第一阶段优先顺序
|
||
|
||
本文件不定义行业方案细节，只定义引擎功能版图、当前成熟度和优先级。
|
||
|
||
## 定义原则
|
||
|
||
### 原则 1：功能清单按引擎系统划分
|
||
|
||
功能项应该是：
|
||
|
||
- 资产系统
|
||
- 模型导入
|
||
- 材质系统
|
||
- Scene / Prefab
|
||
- UI 系统
|
||
- 编辑器框架
|
||
- 渲染系统
|
||
- 运行时发布
|
||
|
||
而不应该是：
|
||
|
||
- 工业模型导入
|
||
- 数据看板
|
||
- 点位绑定
|
||
- 设备监控
|
||
|
||
后者可以作为首个落地场景中的“应用层能力”，但不应主导引擎主清单。
|
||
|
||
### 原则 2：优先做通用能力，再做场景化包装
|
||
|
||
如果一个功能既能服务数字孪生，也能服务未来的工业三维应用、XR 应用或其他交互式 3D 应用，就应该优先按通用引擎方式落地。
|
||
|
||
### 原则 3：第一阶段仍然允许场景驱动
|
||
|
||
第一阶段不是做“全功能 Unity 替代品”，而是做：
|
||
|
||
**一个足够完整、可交付、可继续演进的引擎基础版本。**
|
||
|
||
所以这份清单会特别强调：
|
||
|
||
- 哪些能力必须进入第一阶段
|
||
- 哪些能力可以在第一阶段只做骨架
|
||
|
||
## 能力分层总览
|
||
|
||
MetaCore 当前应按下列 12 个引擎能力域来规划：
|
||
|
||
1. 项目与资源体系
|
||
2. 资源类型支持
|
||
3. 场景与对象系统
|
||
4. Component 与序列化体系
|
||
5. Prefab 系统
|
||
6. 渲染与视觉系统
|
||
7. 编辑器框架
|
||
8. UI 系统
|
||
9. 逻辑与脚本层
|
||
10. 输入与交互框架
|
||
11. 运行时与发布体系
|
||
12. 工程基础设施
|
||
|
||
下文对每个能力域给出：
|
||
|
||
- 定义
|
||
- 当前状态
|
||
- 第一阶段目标
|
||
- 优先级
|
||
|
||
---
|
||
|
||
## 1. 项目与资源体系
|
||
|
||
### 定义
|
||
|
||
负责项目组织、资源身份、元数据、导入、重导入、资源查询、依赖更新和构建产物管理。
|
||
|
||
### 目标能力
|
||
|
||
- 创建和打开项目
|
||
- 项目目录结构约定
|
||
- 资源 GUID
|
||
- meta 文件
|
||
- 资源数据库
|
||
- 导入管线
|
||
- 重新导入
|
||
- 资源依赖跟踪
|
||
- cooked 产物管理
|
||
- 资源搜索、过滤、分组
|
||
|
||
### 当前状态
|
||
|
||
`已具备`
|
||
|
||
- 项目描述文件与项目目录语义
|
||
- 资源数据库基础接口
|
||
- GUID / 资源记录 / 相对路径查询
|
||
- 导入、重导入、cook 服务接口
|
||
- `.mcmeta`、`.mcasset`、cooked 结果等基础概念
|
||
|
||
`部分具备`
|
||
|
||
- 资源导入通路已经打通
|
||
- 资源刷新和重新导入已有测试覆盖
|
||
- 项目结构已经在编辑器服务层内建模
|
||
|
||
`薄弱或缺失`
|
||
|
||
- 完整依赖图
|
||
- 子资产体系
|
||
- 资源缩略图与预览缓存
|
||
- 资源标签、搜索索引、过滤体系
|
||
- 资源移动/重命名后的引用自动修复
|
||
- 平台化 import / cook profile
|
||
|
||
### 第一阶段目标
|
||
|
||
- 把资源系统做成稳定主干，而不是分散在工具函数中的辅助逻辑
|
||
- 支撑内容工作流的日常使用
|
||
- 为模型、材质、UI、Prefab 等资源类型提供统一入口
|
||
|
||
### 优先级
|
||
|
||
`P0`
|
||
|
||
---
|
||
|
||
## 2. 资源类型支持
|
||
|
||
### 定义
|
||
|
||
负责定义引擎支持哪些一等资源类型，以及每种资源的导入、编辑、引用和运行时消费方式。
|
||
|
||
### 目标能力
|
||
|
||
- 模型资源
|
||
- 网格资源
|
||
- 材质资源
|
||
- 纹理资源
|
||
- Shader 资源
|
||
- Scene 资源
|
||
- Prefab 资源
|
||
- UI 资源
|
||
- 动画资源
|
||
- 音频资源
|
||
- 配置类资源
|
||
|
||
### 当前状态
|
||
|
||
`已具备`
|
||
|
||
- Scene 资源
|
||
- Runtime 配置类资源
|
||
- UI 文档序列化基础
|
||
- Prefab 相关接口和元数据方向
|
||
|
||
`部分具备`
|
||
|
||
- 模型导入已经有明显的设计和测试痕迹
|
||
- 纹理导入至少有基础工作链路
|
||
- 材质和网格数据结构已经在相关设计文档中展开
|
||
|
||
`薄弱或缺失`
|
||
|
||
- 成熟的模型资源定义
|
||
- 材质资源编辑器
|
||
- 纹理 import settings
|
||
- Shader 资源工作流
|
||
- 动画资源
|
||
- 音频资源
|
||
- 字体资源
|
||
- 脚本资源
|
||
|
||
### 第一阶段目标
|
||
|
||
- 至少把模型、纹理、材质、Scene、Prefab、UI 这六类资源做成真正可用的一等资源
|
||
|
||
### 优先级
|
||
|
||
`P0`
|
||
|
||
---
|
||
|
||
## 3. 场景与对象系统
|
||
|
||
### 定义
|
||
|
||
负责场景容器、对象层级、Transform、对象生命周期、选择、复制、删除、场景保存与加载。
|
||
|
||
### 目标能力
|
||
|
||
- Scene / SubScene
|
||
- GameObject / Component
|
||
- Transform 层级
|
||
- 对象创建、复制、删除、重命名
|
||
- 重挂接
|
||
- 多选与批量编辑
|
||
- 场景保存、加载、另存
|
||
- 启动场景
|
||
|
||
### 当前状态
|
||
|
||
`已具备`
|
||
|
||
- Scene 容器
|
||
- GameObject + Component 基础模型
|
||
- Transform 层级
|
||
- 创建、查找、删除、复制、重挂接
|
||
- 场景快照
|
||
- 场景保存/加载基础
|
||
- 选择、多选、活动对象等编辑态基础
|
||
|
||
`部分具备`
|
||
|
||
- Undo / Redo 已有可用基础
|
||
- 启动场景加载链路已打通
|
||
- Scene 视图交互已经形成基本工作流
|
||
|
||
`薄弱或缺失`
|
||
|
||
- 多场景编辑
|
||
- SubScene / 流式场景
|
||
- 大场景组织能力
|
||
- 场景引用检查与修复工具
|
||
- 更成熟的批量编辑
|
||
|
||
### 第一阶段目标
|
||
|
||
- 把场景系统从“原型可演示”推进到“可持续编辑和交付”
|
||
|
||
### 优先级
|
||
|
||
`P0`
|
||
|
||
---
|
||
|
||
## 4. Component 与序列化体系
|
||
|
||
### 定义
|
||
|
||
负责对象可组合能力、反射、序列化、组件注册、组件编辑、复制粘贴和版本兼容。
|
||
|
||
### 目标能力
|
||
|
||
- 内建组件库
|
||
- 组件注册与发现
|
||
- 反射
|
||
- 序列化
|
||
- 组件复制/粘贴
|
||
- 组件默认值与重置
|
||
- 组件依赖声明
|
||
- 编辑态 / 运行态约束
|
||
|
||
### 当前状态
|
||
|
||
`已具备`
|
||
|
||
- 自定义反射系统
|
||
- 代码生成工具链
|
||
- 序列化基础
|
||
- 组件描述注册接口
|
||
- Inspector drawer 框架
|
||
|
||
`部分具备`
|
||
|
||
- 当前组件类型虽然不多，但基础抽象方向正确
|
||
- 测试已覆盖部分组件注册与操作能力
|
||
|
||
`薄弱或缺失`
|
||
|
||
- 更丰富的内建组件
|
||
- 完整组件生命周期
|
||
- 组件依赖校验
|
||
- 版本迁移与兼容机制
|
||
- 编辑态 / 运行态隔离规则
|
||
|
||
### 第一阶段目标
|
||
|
||
- 保证 Scene、渲染、UI、交互所需的基础组件体系可扩展且可稳定序列化
|
||
|
||
### 优先级
|
||
|
||
`P0`
|
||
|
||
---
|
||
|
||
## 5. Prefab 系统
|
||
|
||
### 定义
|
||
|
||
负责对象模板、实例化、覆盖记录、应用与回退，以及内容复用效率。
|
||
|
||
### 目标能力
|
||
|
||
- Prefab 创建
|
||
- Prefab 实例化
|
||
- Override 记录
|
||
- Apply / Revert
|
||
- 嵌套 Prefab
|
||
- Variant
|
||
- 实例同步
|
||
|
||
### 当前状态
|
||
|
||
`已具备`
|
||
|
||
- Prefab 元数据结构
|
||
- Prefab 服务接口
|
||
- 测试覆盖了 prefab workflow
|
||
|
||
`部分具备`
|
||
|
||
- 基础工作流很可能已经打通一版
|
||
- 但产品级编辑体验还没成型
|
||
|
||
`薄弱或缺失`
|
||
|
||
- Override 可视化
|
||
- 嵌套 Prefab
|
||
- Prefab Variant
|
||
- 批量实例同步
|
||
- 更清晰的编辑器交互
|
||
|
||
### 第一阶段目标
|
||
|
||
- 至少做到“可创建、可实例化、可修改、可应用、可回退”
|
||
|
||
### 优先级
|
||
|
||
`P0`
|
||
|
||
---
|
||
|
||
## 6. 渲染与视觉系统
|
||
|
||
### 定义
|
||
|
||
负责渲染抽象、材质应用、光照、相机、视口和视觉调试能力。
|
||
|
||
### 目标能力
|
||
|
||
- 渲染设备抽象
|
||
- Scene 渲染
|
||
- 摄像机系统
|
||
- 灯光系统
|
||
- 材质与 Shader 绑定
|
||
- 基础 PBR
|
||
- 阴影
|
||
- 天空盒 / 环境光
|
||
- Gizmo / Debug Draw
|
||
- 后处理框架
|
||
|
||
### 当前状态
|
||
|
||
`已具备`
|
||
|
||
- Panda3D 宿主和渲染桥
|
||
- 编辑器视口渲染
|
||
- 基础场景显示
|
||
- 摄像机、网格、灯光、调试叠加
|
||
- Gizmo 和 Scene overlay 基础
|
||
|
||
`部分具备`
|
||
|
||
- 渲染抽象已经存在
|
||
- 视口交互体验已经能支持基本编辑工作
|
||
|
||
`薄弱或缺失`
|
||
|
||
- 完整材质系统
|
||
- Shader 资源与管线
|
||
- 稳定 PBR 工作流
|
||
- 阴影质量和配置
|
||
- 环境光与天空盒体系
|
||
- 后处理框架
|
||
- 更系统的调试视图
|
||
|
||
### 第一阶段目标
|
||
|
||
- 支撑日常三维场景制作和演示
|
||
- 不追求游戏引擎广度，但要保证视觉系统不是阻塞项
|
||
|
||
### 优先级
|
||
|
||
`P1`
|
||
|
||
---
|
||
|
||
## 7. 编辑器框架
|
||
|
||
### 定义
|
||
|
||
负责编辑器主壳、面板系统、菜单系统、Inspector、Project Browser、命令系统和扩展接口。
|
||
|
||
### 目标能力
|
||
|
||
- Docking 工作流
|
||
- Hierarchy / Inspector / Project / Console
|
||
- Scene View / Game View
|
||
- 菜单系统
|
||
- 面板系统
|
||
- Inspector 绘制框架
|
||
- 快捷键体系
|
||
- 命令系统
|
||
- 可扩展模块机制
|
||
|
||
### 当前状态
|
||
|
||
`已具备`
|
||
|
||
- Docking 编辑器壳
|
||
- Hierarchy / Inspector / Project / Console 基础
|
||
- Scene View
|
||
- 菜单与面板 provider 机制
|
||
- 服务注册与模块机制
|
||
- 命令系统基础
|
||
|
||
`部分具备`
|
||
|
||
- 内建模块已经能组合出基本编辑流程
|
||
- 编辑器主框架的模块边界相对清晰
|
||
|
||
`薄弱或缺失`
|
||
|
||
- 更成熟的 Project Browser
|
||
- Game View 的完整语义
|
||
- 拖拽式资源工作流
|
||
- 上下文菜单体系
|
||
- 通用搜索
|
||
- 更稳定的布局持久化
|
||
- 更强的插件扩展边界
|
||
|
||
### 第一阶段目标
|
||
|
||
- 把编辑器做成稳定生产工具，而不是只具备面板展示能力
|
||
|
||
### 优先级
|
||
|
||
`P0`
|
||
|
||
---
|
||
|
||
## 8. UI 系统
|
||
|
||
### 定义
|
||
|
||
负责 UI 资源格式、布局、控件、事件、运行时渲染和 UI 编辑器。
|
||
|
||
### 目标能力
|
||
|
||
- UI 文档格式
|
||
- UI 节点模型
|
||
- 布局系统
|
||
- 控件库
|
||
- 样式系统
|
||
- UI 事件系统
|
||
- UI 编辑器
|
||
- 运行时 UI 渲染
|
||
- 分辨率适配
|
||
|
||
### 当前状态
|
||
|
||
`已具备`
|
||
|
||
- `UiDocument` 基础模型
|
||
- UI 资源序列化测试
|
||
|
||
`部分具备`
|
||
|
||
- UI 资源已经从架构上被当作独立系统看待
|
||
|
||
`薄弱或缺失`
|
||
|
||
- UI 编辑器
|
||
- 运行时 UI 渲染
|
||
- 控件库
|
||
- 布局系统
|
||
- 样式编辑
|
||
- 事件系统
|
||
- 分辨率适配
|
||
|
||
### 第一阶段目标
|
||
|
||
- 至少实现可用于构建基础工具界面和运行时 HUD 的 UI 系统
|
||
|
||
### 优先级
|
||
|
||
`P1`
|
||
|
||
---
|
||
|
||
## 9. 逻辑与脚本层
|
||
|
||
### 定义
|
||
|
||
负责运行时行为组织、脚本能力、生命周期、状态驱动和时间系统。
|
||
|
||
### 目标能力
|
||
|
||
- 行为组件执行框架
|
||
- 运行时生命周期
|
||
- 时间系统
|
||
- 调度与定时器
|
||
- 事件驱动逻辑
|
||
- 脚本系统或脚本系统预留
|
||
|
||
### 当前状态
|
||
|
||
`已具备`
|
||
|
||
- 一些服务式运行时组织思路
|
||
- 编辑态 / 运行态开始有边界
|
||
|
||
`部分具备`
|
||
|
||
- 通过组件和服务能承载部分简单逻辑
|
||
|
||
`薄弱或缺失`
|
||
|
||
- 系统化脚本层
|
||
- 行为执行框架
|
||
- 生命周期函数模型
|
||
- 统一的时间/调度抽象
|
||
- 可视逻辑系统
|
||
|
||
### 第一阶段目标
|
||
|
||
- 第一阶段允许只做骨架和关键扩展点
|
||
- 但必须避免后续无法叠加行为层
|
||
|
||
### 优先级
|
||
|
||
`P1`
|
||
|
||
---
|
||
|
||
## 10. 输入与交互框架
|
||
|
||
### 定义
|
||
|
||
负责编辑态和运行态输入抽象、交互映射和事件分发。
|
||
|
||
### 目标能力
|
||
|
||
- 键盘鼠标输入
|
||
- 输入映射
|
||
- Action / Axis 抽象
|
||
- UI 输入路由
|
||
- 运行态交互事件
|
||
- 未来触摸 / 手柄 / XR 输入预留
|
||
|
||
### 当前状态
|
||
|
||
`已具备`
|
||
|
||
- 输入采集
|
||
- Scene 视口交互
|
||
- 相机控制
|
||
- 对象选择与 Gizmo 操作
|
||
|
||
`部分具备`
|
||
|
||
- 编辑态交互已经有不错的基础
|
||
|
||
`薄弱或缺失`
|
||
|
||
- 运行时输入映射系统
|
||
- Action / Axis 层
|
||
- 输入配置资源
|
||
- UI 输入路由
|
||
- 更通用的交互系统
|
||
|
||
### 第一阶段目标
|
||
|
||
- 编辑态交互成熟化
|
||
- 运行态交互抽象至少具备扩展骨架
|
||
|
||
### 优先级
|
||
|
||
`P1`
|
||
|
||
---
|
||
|
||
## 11. 运行时与发布体系
|
||
|
||
### 定义
|
||
|
||
负责 Player、项目构建、内容部署、运行时配置和发布产物管理。
|
||
|
||
### 目标能力
|
||
|
||
- Player
|
||
- 构建配置
|
||
- 资源打包与部署
|
||
- 启动场景接管
|
||
- 发布目录结构
|
||
- runtime 配置
|
||
- 日志与诊断
|
||
- 版本兼容
|
||
|
||
### 当前状态
|
||
|
||
`已具备`
|
||
|
||
- `MetaCorePlayer`
|
||
- 启动场景加载
|
||
- runtime 配置读取
|
||
- 独立 player 入口
|
||
|
||
`部分具备`
|
||
|
||
- build / cook / runtime 目录语义已建立
|
||
- 打包交付方向已有设计文档支撑
|
||
|
||
`薄弱或缺失`
|
||
|
||
- 完整打包发布流程
|
||
- clean machine 验证机制
|
||
- 多配置构建 profile
|
||
- 资源部署规范
|
||
- 版本迁移和兼容流程
|
||
|
||
### 第一阶段目标
|
||
|
||
- 做出真正可交付的独立运行时闭环
|
||
|
||
### 优先级
|
||
|
||
`P0`
|
||
|
||
---
|
||
|
||
## 12. 工程基础设施
|
||
|
||
### 定义
|
||
|
||
负责构建系统、测试体系、代码生成、诊断、性能回归和文档支撑。
|
||
|
||
### 目标能力
|
||
|
||
- 构建系统
|
||
- 测试框架
|
||
- 反射代码生成
|
||
- 性能分析
|
||
- 崩溃与诊断
|
||
- 自动化验证
|
||
- 文档基线
|
||
|
||
### 当前状态
|
||
|
||
`已具备`
|
||
|
||
- CMake + vcpkg
|
||
- 反射代码生成工具
|
||
- 较强的 smoke test 覆盖
|
||
- 模块分层基本清晰
|
||
|
||
`部分具备`
|
||
|
||
- 测试已经覆盖多个跨模块能力
|
||
- 崩溃日志与基础诊断已有起点
|
||
|
||
`薄弱或缺失`
|
||
|
||
- 更细粒度单元测试
|
||
- 基准测试和性能回归
|
||
- 更系统的崩溃诊断工具链
|
||
- 资产一致性检查工具
|
||
- API 稳定性边界说明
|
||
|
||
### 第一阶段目标
|
||
|
||
- 保证基础能力迭代不会频繁回归
|
||
|
||
### 优先级
|
||
|
||
`P1`
|
||
|
||
---
|
||
|
||
## 当前总体成熟度判断
|
||
|
||
以下数字不是精确测量，而是基于当前仓库代码、测试和文档的工程判断。
|
||
|
||
| 能力域 | 成熟度判断 |
|
||
| --- | --- |
|
||
| 项目与资源体系 | 40% |
|
||
| 资源类型支持 | 30% |
|
||
| 场景与对象系统 | 55% |
|
||
| Component 与序列化体系 | 50% |
|
||
| Prefab 系统 | 30% |
|
||
| 渲染与视觉系统 | 35% |
|
||
| 编辑器框架 | 60% |
|
||
| UI 系统 | 20% |
|
||
| 逻辑与脚本层 | 15% |
|
||
| 输入与交互框架 | 45% |
|
||
| 运行时与发布体系 | 30% |
|
||
| 工程基础设施 | 55% |
|
||
|
||
## 第一阶段建议优先级
|
||
|
||
### P0：主干能力
|
||
|
||
- 项目与资源体系
|
||
- 资源类型支持中的模型、纹理、材质、Scene、Prefab、UI
|
||
- 场景与对象系统
|
||
- Component 与序列化体系
|
||
- Prefab 系统
|
||
- 编辑器框架
|
||
- 运行时与发布体系
|
||
|
||
### P1：紧随主干补强
|
||
|
||
- 渲染与视觉系统
|
||
- UI 系统
|
||
- 逻辑与脚本层骨架
|
||
- 输入与交互框架
|
||
- 工程基础设施增强
|
||
|
||
### P2：在主干稳定后继续推进
|
||
|
||
- 更完整的脚本层
|
||
- 更丰富的渲染能力
|
||
- 更强的插件化
|
||
- 更广泛的资源类型支持
|
||
- 跨平台与 XR 预留深化
|
||
|
||
## 当前仓库能力映射
|
||
|
||
下面这些代码入口已经能支撑本清单中的部分能力：
|
||
|
||
- 编辑器服务与项目/资源抽象：[MetaCoreEditorServices.h](D:/MetaCore/Source/MetaCoreEditor/Public/MetaCoreEditor/MetaCoreEditorServices.h)
|
||
- 编辑器模块与扩展机制：[MetaCoreEditorModule.h](D:/MetaCore/Source/MetaCoreEditor/Public/MetaCoreEditor/MetaCoreEditorModule.h)
|
||
- 场景系统：[MetaCoreScene.h](D:/MetaCore/Source/MetaCoreScene/Public/MetaCoreScene/MetaCoreScene.h)
|
||
- 对象模型：[MetaCoreGameObject.h](D:/MetaCore/Source/MetaCoreScene/Public/MetaCoreScene/MetaCoreGameObject.h)
|
||
- 编辑器主壳与工作流：[MetaCoreEditorApp.cpp](D:/MetaCore/Source/MetaCoreEditor/Private/MetaCoreEditorApp.cpp)
|
||
- 运行时入口：[main.cpp](D:/MetaCore/Apps/MetaCorePlayer/main.cpp)
|
||
- 跨模块烟雾测试：[MetaCoreSmokeTests.cpp](D:/MetaCore/tests/MetaCoreSmokeTests.cpp)
|
||
|
||
## 建议的后续文档拆分
|
||
|
||
在本文件之上，建议继续拆出三类文档：
|
||
|
||
1. `MetaCore 引擎能力状态表`
|
||
- 把每个能力项拆成“已完成 / 在建 / 未开始”
|
||
|
||
2. `MetaCore 第一阶段里程碑文档`
|
||
- 把 P0 / P1 映射到具体 M1、M2、M3、M4
|
||
|
||
3. 单系统设计文档
|
||
- 资产系统设计
|
||
- Prefab 系统设计
|
||
- UI 系统设计
|
||
- 渲染材质系统设计
|
||
- 运行时发布系统设计
|
||
|
||
## 结论
|
||
|
||
MetaCore 的主功能清单应始终按“引擎能力”来描述。
|
||
|
||
第一阶段虽然以数字孪生项目为首个落地方向，但这不应改变 MetaCore 的本质定位：
|
||
|
||
**MetaCore 要先成为一个结构正确、能力完整度持续上升的引擎，再成为一个面向特定行业场景交付的解决方案底座。**
|
||
|
||
因此，第一阶段最重要的不是堆更多行业功能，而是持续补齐引擎主干：
|
||
|
||
- 资源
|
||
- 导入
|
||
- Scene
|
||
- Prefab
|
||
- 材质
|
||
- UI
|
||
- 编辑器工作流
|
||
- Player / Build / 发布
|
||
|
||
这条主干越稳，后续任何场景化方案层都越容易叠加。
|