The most important feature of Numivo is invisible: your shipped game contains none of it. Every tool in the box — scatter, mesh blending, grids — produces plain engine assets and nothing else. This post explains what that means technically, and why we consider it non-negotiable.
What "native" means concretely
When you bake a scatter pass in Unreal, Numivo writes Hierarchical Instanced Static Mesh components or foliage instances — the same structures you'd get placing things by hand. In Unity, it's standard prefab instances or terrain details. Materials from mesh blending compile down to regular engine materials with pixel-perfect normal transitions; there is no custom shader pass, no per-frame plugin work, no "Numivo runtime" module in your Build.cs or your package manifest.
The numbers that follow from this:
- 0 lines of Numivo code in your build
- 0 ms added frame time — there is nothing to execute
- < 150 MB editor RAM in typical scenes, because the editor tooling is the whole footprint
- 1 shared core across Unreal and Unity, so presets transfer between engines
Why we refuse a runtime dependency
Runtime dependencies are debt that someone else has to pay:
- Certification. Console cert teams ask what every third-party module does. "There isn't one" is the shortest possible answer.
- Longevity. Games outlive tool subscriptions. Because baked results are ordinary assets, a scene built with Numivo opens and ships in ten years, with or without us. If you cancel, you keep everything you made — that's not a promise in our terms, it's a property of the architecture.
- Performance ownership. Your profiler shows engine primitives you already know how to optimize — cull distances, LODs, Nanite settings — not a black box.
What it means for your repo
Baked results version like any other asset: they diff, they merge, they review. Numivo's species and grid presets are small plain files you can commit and share with your team. The only thing that should not go into version control is the local content-index cache (it rebuilds itself); one ignore rule and you're done.
The trade-off, stated honestly
Non-destructive procedural editing needs the plugin: once baked, a hillside is engine data, and re-editing it procedurally means re-opening it with Numivo. We think that's the right trade — the alternative (keeping scenes dependent on a runtime layer) quietly holds your project hostage. Your levels should belong to your game, not to your tools.
If that philosophy matches how your team works, the free tier is the easiest way to test it: scatter something, bake it, delete the plugin, and watch the scene not care.
