Numivo 最重要的功能是看不见的：你发布的游戏里一点都没有它。 盒子里的每件工具——散布、 网格混合、Grids——都只生成普通的引擎资产，别无其他。本文解释这在技术上意味着什么，以及 我们为何认为这一点没有商量余地。
“原生”具体意味着什么
当你在 Unreal 中烘焙一次散布时，Numivo 写入的是 Hierarchical Instanced Static Mesh 组件 或 植被实例——与你手动摆放所得到的结构完全相同。在 Unity 中，则是标准的预制体 实例或地形细节。来自网格混合的材质会编译为普通的引擎材质，并带有像素级精确的法线过渡； 没有自定义着色器通道，没有逐帧的插件工作，你的 Build.cs 或包清单里也没有任何“Numivo 运行时”模块。
由此得出的数字：
- 你的构建中含有 0 行 Numivo 代码
- 增加的帧时间为 0 ms——没有任何东西需要执行
- 典型场景下编辑器内存 < 150 MB，因为编辑器工具就是全部占用
- 跨 Unreal 与 Unity 的共享核心为 1 个，所以预设可以在引擎之间迁移
我们为何拒绝运行时依赖
运行时依赖是一笔债务，得由别人来偿还：
- 认证。 主机认证团队会问每一个第三方模块都做了什么。“没有这种模块”是最短的回答。
- 寿命。 游戏比工具订阅活得更久。因为烘焙结果是普通资产，用 Numivo 搭建的场景在十年后 依然能打开、能发布，无论我们是否还在。若你取消订阅，你所做的一切都归你所有——这不是我们 条款里的承诺，而是架构本身的属性。
- 性能掌控权。 你的性能分析器显示的是你早已知道如何优化的引擎图元——剔除距离、LOD、 Nanite 设置——而不是一个黑盒。
这对你的仓库意味着什么
烘焙结果像任何其他资产一样纳入版本管理：可 diff、可合并、可评审。Numivo 的物种与网格预设 是可以提交并与团队共享的小巧朴素文件。唯一不应进入版本控制的是本地内容索引缓存（它会 自行重建）；一条忽略规则即可搞定。
坦诚说明这项取舍
非破坏性的程序化编辑需要插件：一旦烘焙，一片山坡就是引擎数据，要对它进行程序化再编辑，就意味着 用 Numivo 重新打开它。我们认为这是正确的取舍——另一种选择（让场景依赖于运行时层）会悄悄地把 你的项目扣为人质。你的关卡应当属于你的游戏，而不是属于你的工具。
如果这套理念契合你团队的工作方式，免费层是检验它最简单的方式：散布一些东西， 把它烘焙，删除插件，然后看着场景毫不在意。