gengjiayuan/MetaCore

Fork 0

ayuan9957 9a33e9f243 Advance editor workflows and add UI and simplepbr foundations

2026-03-30 08:30:28 +08:00

9.5 KiB

Raw Blame History

MetaCore M1-M2 详细任务分解

生成时间：2026-03-28
状态：草案
范围：M1 引擎壳与项目循环，M2 资源与模型导入循环

目的

这份文档把当前最应该推进的两个里程碑拆成真正可执行的任务单。

它不是概念清单，而是用于直接指导后续开发排序、拆工和验收的。

当前原则：

先把引擎基础工作流做扎实
不再让 RuntimeData 继续主导第一阶段节奏
所有任务都要服务于“像 Unity / UE 一样完成工业项目开发”的最小生产力闭环

当前代码基础判断

结合现有仓库，MetaCore 已经具备一些可以复用的基础：

项目描述文件读取基础
资源数据库与 package 基础能力
场景保存/加载二进制方向
基础层级编辑能力
基础 Inspector
基础 prefab 能力
独立 Player

但当前真正缺的是：

把项目系统做成稳定入口
把导入流程做成真正可用的资源工作流
把模型导入从“识别格式”推进到“可用于场景”
把 Project 面板、资源引用、重新导入和 package 行为串成闭环

所以 M1-M2 的目标不是“继续补零散能力”，而是把这条主链打通：

打开项目
  -> 浏览资源
    -> 导入模型
      -> 模型变成可引用资产
        -> 放入场景
          -> 保存并重开仍然有效

M1：引擎壳与项目循环

M1 目标

把 MetaCore 做成一个稳定的“项目入口”，而不只是一个能打开窗口的编辑器。

M1 完成标准

能稳定定位和打开项目
项目描述文件能被一致读取和保存
启动场景机制稳定
Editor 和 Player 都能围绕项目根目录工作
新老路径兼容行为清晰，不再依赖临时 fallback 才能运行

M1 工作包

M1-A 项目定位与启动逻辑统一

目标

统一 Editor、Player、工具对项目根目录的解析逻辑。

现状

当前代码里已经存在多处项目路径解析和 fallback 逻辑，但它们分散在不同入口。

任务

抽出统一的项目路径解析帮助层
统一 MetaCore.project.json 定位逻辑
统一 startup scene 解析逻辑
统一 Runtime 目录定位逻辑
明确命令行传项目路径与默认样板项目路径的优先级

交付物

一个公共项目路径解析入口
Editor/Player/工具共用同一套项目根解析规则

验收

从不同当前工作目录启动时仍能打开同一个项目
样板项目不依赖“碰巧的相对路径”才能运行

M1-B 项目描述文件能力补齐

目标

把 MetaCore.project.json 做成真正的项目描述文件，而不是只存一个 startup scene。

建议字段

当前至少明确以下字段：

name
version
startup_scene
scenes
runtime_config 或转向固定 runtime 目录策略
未来可预留 asset_roots、ui_roots

任务

梳理项目描述文件的最小字段集
统一读写逻辑
明确旧字段兼容策略
对非法项目描述给出明确错误

验收

坏项目文件能报错
缺字段时行为一致
保存后再次打开结果一致

M1-C 启动场景工作流稳定化

目标

确保项目和启动场景关系稳定。

任务

明确 startup scene 的设置入口
明确 startup scene 保存后项目描述同步规则
明确启动场景缺失时的行为
Player 和 Editor 对 startup scene 的解释保持一致

验收

设置 startup scene 后，Editor/Player 行为一致
场景改名或移动后，引用更新策略清晰

M1-D 样板项目 bootstrap 规则

目标

样板项目成为可持续维护的基线项目，而不是演示残留物。

任务

固定样板项目目录结构
固定 Scenes / Assets / Runtime / Library 的职责
明确自动生成内容与手工维护内容边界
把当前样板工程转成规范项目

验收

新人能直接理解样板项目结构
工具生成文件不会污染错误目录

M1-E 项目级测试

目标

给项目循环加回归保护。

必测项

项目描述读取
startup scene 读取
startup scene 缺失处理
项目根目录解析
Player 项目启动链

M2：资源与模型导入循环

M2 目标

把 MetaCore 变成一个真正围绕资源工作的工具，而不是只围绕内建对象工作的编辑器。

M2 完成标准

导入的资源进入 Asset Database
模型资源成为可追踪资产
Project 面板能看见并定位这些资源
导入资源能被放进场景并在保存后重开
重新导入和元数据行为稳定

M2 工作包

M2-A 导入器策略收敛

目标

明确第一阶段首批导入策略，不再模糊支持。

建议首批格式

P0：glTF/.glb
P1：FBX
P2：OBJ

理由

glTF/.glb 更适合作为第一生产级导入格式
FBX 很重要，但复杂度高，不应该先把整条链卡死在 FBX 上
OBJ 可作为简化补充，不应该主导设计

任务

明确导入器接口的能力边界
区分“识别格式”和“完整导入能力”
明确哪些格式只是注册，哪些格式是真生产支持

验收

文档和代码里对格式支持口径一致

M2-B 模型资源数据模型

目标

给模型资源一个稳定的数据表示，不要只把原始文件名记进数据库。

最低要求

资源 GUID
资源类型
原始源文件路径
package 路径
导入器 id
源文件 hash
模型节点层级信息的承载位置

任务

明确“模型资产”和“导入源文件”的关系
明确 package 里到底存什么
明确导入后场景引用的是什么对象

验收

一个模型导入后有明确资产身份
场景引用模型时不依赖源文件路径硬绑

M2-C 模型导入最小闭环

目标

把至少一种格式做成真的可用，而不是仅识别扩展名。

闭环要求

选择模型文件导入
生成资产记录
生成 package
Project 面板里可见
放进场景后可渲染
保存场景后重开仍然存在

验收

至少一个 glTF/.glb 样例能完整跑通上述闭环

M2-D 层级保留与归一化

目标

导入模型时不要只保一个“单网格结果”，要为数字孪生常见设备结构保留层级。

任务

保留模型节点层级
明确坐标系转换
明确缩放归一化
明确材质槽映射
明确空节点是否保留

验收

导入后层级结构与源模型基本一致
不会出现方向、缩放完全错误的基础问题

M2-E 重新导入策略

目标

资源改动后可刷新，而不是删了重来。

任务

基于源 hash 检测变化
明确重新导入触发方式
明确重新导入后 package 更新规则
明确重新导入对场景引用的影响

验收

修改源模型后可稳定刷新
场景里的引用不被无故打断

M2-F Project 面板与资源浏览增强

目标

让资源工作流真正可用。

必须支持

浏览项目资源
区分 source / meta / package
定位资源
显示资源类型
打开场景资产
未来可扩展到双击实例化模型

任务

补齐资源显示信息
强化 scene / prefab / asset 的区分
明确从资源到场景的最小放置流程

验收

用户能在 Project 面板里明确找到导入的模型资产

M2-G 导入错误与诊断

目标

导入失败要可定位。

必须可见的错误类型

文件不存在
格式不支持
package 写入失败
元数据损坏
重新导入失败

验收

失败不会静默
Console 有明确错误类别和信息

M2-H M2 测试矩阵

目标

给资源与导入闭环加回归保护。

必测项

项目导入一个模型
生成 metadata
生成 package
Asset Database 记录稳定
Project 面板可见
场景引用导入资源
保存并重开仍然有效
重新导入不打断引用

当前代码库下的优先实现建议

基于现有仓库状态，我建议最先动这几条：

第一批

项目路径与项目描述统一
startup scene 行为统一
导入器支持口径收敛
glTF/.glb 作为第一优先格式定下来

第二批

模型资产数据结构
最小模型导入闭环
Project 面板识别模型资产

第三批

重新导入
导入错误诊断
资源引用稳定性

Definition of Done

M1-M2 完成时，MetaCore 至少要做到：

能稳定打开项目
能稳定打开 startup scene
能导入第一种正式支持的模型格式
能在 Project 面板里看到模型资产
能把模型资产放进场景
场景保存、重开后模型仍然有效
打包链路不会因为导入资产而断掉

9.5 KiB Raw Blame History Unescape Escape