# 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 / 发布 这条主干越稳，后续任何场景化方案层都越容易叠加。