路线图

对着源码审计，而不是对着先前的文档。缺失的行和已发布的行 出现在这里是出于同一个原因：你应该能仅凭引擎自己的文档 做出取舍，并且在第一天而不是第三周发现真相。

完整的工作文档在仓库里，即 Roadmap.md， 包含每个排序决定背后的依赖推理。本页是它的公开摘要。

基线：渲染

一个决定上面几项成本的事实。 管线是 前向渲染——管线状态组织为 Opaque / Transparent / Fade 加剔除变体， 带一个可存储的深度目标和速度目标。没有 G-buffer。 这就是反射和贴花被门控在新增法线目标之后、延迟贴花 不是简单的“下一项”的原因。

基线：宿主与世界编辑

基线：AI 与基础

基础这一块刻意不粉饰。项目的核心主张是架构极简 能赚回托管运行时花掉的成本——而这个主张目前没有任何测量支撑。 修复它是 D 轨的事，而且它没有被排在后面。

工作如何分组

工作按轨道分组，每条轨道对应项目实际面对的问题。每条轨道 内部的排序按依赖关系，而不是按吸引力——几个诱人的特性排在 后面，因为它们的先决条件是横跨四个后端的基础设施工作。

A 轨 — 渲染

其中三项根本不是特性，而是其他项所依赖的基础设施。它们 不光彩，而且没有一项能产出一张截图，这正是它们被明确点名、 而不是在构建粒子做到一半时才被发现的原因。

为什么顺序长这样。

• 运动模糊排第一，因为它几乎免费：速度缓冲已经存在，TAA 已经在消费它。缺的只是一个解析内核。
• 纹理压缩不是一个视觉特性。它是包体大小、Web 可行性和大多数评估者将要运行的集成 GPU 上可获得的最大单帧时间收益。运行时解码到未压缩是一个明确的非目标。
• SSR 等待法线目标，因为对着深度推导的法线行进、之后再补上缓冲意味着要把解析写两遍。未命中时，SSR 会回退到 DDGI 辐照度图集——没有 GI 体积的引擎必须另发一套反射探针系统，才能避免未命中时一片漆黑。
• GPU 剔除等待一个基准测试，而不仅仅是间接绘制。CPU 视锥剔除已经发布并且默认开启；没有记录在案的基线，就无法证明 GPU 路径更快。在一个托管引擎里有一万个实体时，瓶颈更有可能是逐实体的 Update 开销而不是绘制提交——如果是这样，A7 就是错误的修复。

B 轨 — 宿主与可分享的世界

编辑器是一块演示面板，而不是工作流。它存在是为了让渲染器能被 看见。它不存在于成为引擎被使用的方式。

• B0 — 把外壳从场景中解耦。 今天 Create() 无条件地构建整个岛屿。「不加载任何世界地运行」和「创建一个新世界」是同一种能力，而本轨的一切其他事项都首先需要它。
• B1 — 世界序列化。 设计规则先于格式。
• B2 — 编辑辅助。 先有摆放，然后是小工具，然后是只针对构造参数的属性编辑器，然后是层级检查，最后是撤销。
• B3 — 资产目录，许可证归属是必填列，因为捆绑的资产会随共享世界一起流动。
• B4 — 第二个参考世界：大规模单位调度。 数以万计的独立更新、逐个动画的单位，从一开始就带插桩。它兼作 A7 所需的基准。

反碎片化契约。 一条序列化的世界记录是一个 C# 类型 名加构造参数。它永远不是一袋带着行为碎片的属性。布局是数据； 行为是代码；边界是类型名。正是这一条约束，让它不会变成在检查器里 拼装出来的组件模型。

这种区分必须在格式中明确、在 UI 中可见，否则项目就继承了 它正试图避免的那个依赖问题：一个共享世界因为缺少某个类型 而无声地加载失败。

C 轨 — AI

• C1 — 生成输出进入引擎。 八项生成能力已经发布，但它们没有任何一项输出能变成引擎资产。生成的图像变成材质纹理、变成 2D 精灵，生成的音频变成可播放的音源，一个稳定的生成资产文件夹——以及反向：选中一个对象，把它的当前纹理作为参考发给图生图。工作量小，而且是整张路线图上投入产出比最高的一项。
• C2 — 云端模型加运行时 C# 生成，仅桌面端。一个带流式传输和用户自带密钥的 HTTP 客户端，加上 Roslyn 在运行时编译 C#。架构已经为接收结果塑形：一个行为就是一个 Panel 或 Control 子类，所以一个生成的类只需要被实例化并添加——不需要满足任何序列化格式，不需要向任何组件模型注册。
• C3 — 3D 资产生成，仅静态道具。生成模型只是小头；网格减面、UV 展开、法线修复和一个 glTF 导出器才是工作量所在，而这些今天一样都不存在。
• C4 — 自动绑定。 是研究，不是承诺。在输出质量经过真实角色验证之前，它不会出现在商店清单上。

C2 排在 C3 前面，这与直觉顺序相反。C2 是一个 HTTP 客户端 加一个 Roslyn 宿主；C3 是一条网格管线加一个导出器加一个模型。C2 的 质量由前沿模型供给，免费提升；C3 的质量受限于本地 3D 模型今天能 产出的东西，而那还不是可以直接放进游戏的质量。而且 C2 利用了 本引擎有而竞争对手没有的东西——行为即一个可编译的 C# 类。

运行时 C# 编译在完全 AOT 下不可用，这就排除了 iOS 和 WebAssembly。 这个约束被明说而不是被绕过：该特性本质上是仅桌面端。

D 轨 — 基础

这里的每一项，要么是证明另一条轨道里某个主张的先决条件， 要么是项目在与贡献者接触后存活下来的先决条件。

• D1 — 基准与图像差异回归。 固定相机路径、固定帧数、记录的帧时间、绘制调用数和分配量。加上每个后端的无头参考图像对比：对一个卖点是渲染器是真的的项目来说，一次无声的视觉回归是最昂贵的 bug，而这个代码库实际积累的失败——逐帧缓冲串扰、未清空的图集内存、结构体布局漂移、四个 API 之间的着色器分歧——恰恰是编译检查永远抓不到的那种。
• D2 — 帧分配预算。 纯 C# 引擎只在一条轴线上被否定：GC 停顿，而这会出现在第一条社区帖子里。答案不能是散文。「一万个动画实例下每帧零字节分配」一行话就终结争论；别的都不行。
• D3 — 资产管线，吸收纹理压缩、LOD 生成、网格减面和导入缓存。运行时必须继续直接加载普通 glTF 和普通 PNG：管线是一种优化，永远不是入门门槛。
• D4 — 文档与示例阶梯。 一个 50 行以内的最小 BaseApp、单一概念的示例，以及一份添加 compute 特效的书面教程——这是当前引擎中对贡献者最友好的扩展点，而目前只有读 Ddgi.cs 才能发现它。
• D5 — 平台诚实。 没有回退路径。特性声明需求，不支持的特性以写明原因的方式可见地禁用，后端矩阵由同一来源生成。

E 轨 — VR / XR

渲染器在构造上就是单视图的：每帧一个相机、矩阵按对象捆绑、 静态渲染目标单例、窗口 vsync 帧节奏、仅指针输入和屏幕空间 UI。 其中每一项都是 VR 会打破的假设。所以这条轨道被刻意放在最后—— 它是一个新平台主张，而不是现有平台上的一个特性。

A0.4——逐视图矩阵拆分——被放在 A 轨的早期，正是为了让最难的重构 在这条轨道开始之前很久就付清代价，并且趁场景通道已经为法线 目标敞开的时候做。

阶段视图

日期是意图，不是承诺。

阶段 4 及以后。 A8 网格 LOD 和 A9 地形； C3 静态道具生成；C4 自动绑定，如果质量能证明它值得；E 轨从 Windows 和 Direct3D 12 试点开始，然后是 Quest；Mac 和移动端商店上架。主机技术 适配被承认但无处排期——它受限于 SDK 获取，而 SDK 获取受限于 引擎的地位，而不是工程投入。

非目标

没有这些的路线图只是一张愿望清单。下面每一条都是一个 决定，而不是一处遗漏。

• 在特性数量上与以编辑器为中心的引擎竞争。
• 任何形式的可视化脚本、节点图或检查器拼装行为。
• 在固定调度真正构成限制之前做通用帧图。
• 运行时纹理压缩，或任何解码为未压缩的路径。
• 集中的模板或资产市场。
• 为了跟风而围绕 ECS 重建。如果批量实体更新被证明是瓶颈，答案是一条针对批量实体的定向数据导向路径，而不是整个引擎的范式变更。
• 回退渲染路径。改为能力报告。
• OpenXR 以外的任何 XR 运行时——正是那条杀掉 OpenGL 回退的规则。
• 把主机认证或商店政策当作引擎工作。移植引擎是厂商一侧的事；认证一款已交付的游戏是开发者一侧的事。

如何判断这条路行得通

• 渲染器的主张是可证明的：基准数字和参考图像是发布出来的，而不是描述出来的。
• GC 异议一个数字就能回答。
• 有人能在不读引擎源码的情况下，用十分钟评估这个引擎。
• 生成的资产最终进入场景，而不是进入一个文件夹。
• 添加一种世界类型不需要编写编辑器代码。
• Season/ 保持比特性列表所暗示的更小、更清晰。
• 每个领域一个实现仍然成立——不出现 OpenGL 回退、没有第二种动画格式、没有第二个文本渲染器。

关于排序的分歧是欢迎且有用的。 开一个 issue—— Roadmap.md 里的推理都写了下来，以便被质疑。