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 重新開啟它。我們認為這是正確的取捨——另一種選擇（讓場景依賴於執行時層）會悄悄地把 你的專案扣為人質。你的關卡應當屬於你的遊戲，而不是屬於你的工具。
如果這套理念契合你團隊的工作方式，免費層是檢驗它最簡單的方式：散佈一些東西， 把它烘焙，刪除外掛，然後看著場景毫不在意。