Natsura vs SpeedTree – Choosing a Foundation for the Next Decade
SpeedTree has a long, solid track record in games and film. It does what it set out to do: it’s a dedicated tree modeler with a large feature set and a substantial library.
Natsura exists for teams asking a different question: if you’re building vegetation pipelines for the next decade, do you want another standalone modeler, or a growth engine inside Houdini you can build on?
This page is about that choice.
1. Two different foundations
At a high level, SpeedTree gives you:
- A separate application focused on tree/plant authoring
- A rich set of sliders and procedural controls
- A strong built-in asset library and commercial packs
- Exporters for major engines and DCCs
That works well for teams who are comfortable with “one app for trees, another for everything else”.
Natsura is structurally different:
- It is a procedural foliage toolkit inside Houdini, not a separate DCC
- Under the hood, it’s a graph system: you author growth rules using nodes like Grow, Split, and Repeat, then run them with Simulate
- The node set is open and organised into wrappers (artist-facing nodes) and core nodes (low-level verbs)
In practice, that means:
- Vegetation lives in the same procedural space as your layout, FX, USD, PDG, and world-building
- You’re not locked into one runtime: Unreal, in-house engines, and future platforms can all be fed from the same Houdini + Natsura source of truth
2. Simulate with control
Most tools force you to choose:
- Stay mostly “manual” and accept repetition, or
- Lean into simulation and accept less control
Natsura is built so you don’t have to make that trade-off.
- Wrappers like Grow are designed to feel like modelling tools: you set lengths, widths, branch patterns, forks, and silhouettes in ways that match how artists already think
- Underneath, those nodes build an Apex graph describing structure and behaviour
- Simulate evaluates that graph in a deferred way – resolving rules, Mappings, Effectors, and Decorations into final geometry (simulation)
Practically:
- You can work entirely in “modelling mode” if that’s what the shot needs
- When you want more behaviour (light-seeking, gravity influence, variation over space/time, etc.), you promote parameters into mapping sockets and hook in small graphs instead of rewriting the setup
- Simulation isn’t a mode you’re stuck in – it’s something you dial in where it actually buys you quality or speed
The core idea is simple: keep full control all the time, and add simulation only where it helps.
3. Next-gen workflows
You’ve probably hit this wall before: you want to talk about “age”, “health”, “biome”, “art style”, “soil type”, or “gameplay zones”, but your tools only speak in raw numeric parameters.
Natsura’s approach:
- Core parameters stay structural and concrete: how branches repeat, fork, bend, taper; how crowns form; how density changes along a trunk
- When a parameter matters across a plant or across a forest, you can promote it into a mapping socket and drive it via Mapping and Effectors
- Mappings are small graphs that turn attributes (
u,age, height, custom attributes, effector outputs, etc.) into parameter values
This is how teams can:
- Define their own project-specific ideas (“shade stress”, “species variant”, “biome ID”, “art direction mode”) and have those concepts consistently influence structure
- Express those ideas once and use them for dozens, hundreds, or thousands of trees instead of tuning every asset by hand
Natsura doesn’t bake in a hard-coded “Age” slider. It gives you a framework where your own high-level ideas drive structure in a way that’s repeatable, inspectable, and intuitive.
4. Reduce guesswork
Random seeds and manual tweaking will only get you so far. Natsura lets you plug world-space influences directly into growth:
- Effectors bring in things like gravity, light direction proxies, balance, and (experimentally) collisions as attributes
- Those attributes feed into Mapping and the growth graph, so branches and structures can respond to context instead of growing in a vacuum
In practice:
- You can still build entirely “clean” trees that ignore the environment
- When the shot demands it, you can make forests react to terrain, obstacles, or light directions without reinventing the whole setup
It’s the same graph system; you simply decide when to let the outside world influence it.
5. Game engines, pipelines, and Nanite
Both Natsura and SpeedTree can output meshes into modern engines. The more important question is: where does the real work live?
With Natsura, the work lives upstream:
- Growth, variation, scan extension, and meshing are all authored in Houdini using the Natsura node set
- You can generate hero assets, background forests, and everything in between from the same recipes
- Natsura has workflows for UE5/Nanite foliage and skeletal assemblies out of the box (learn more)
Because the source of truth is a Houdini graph, not a single runtime:
- Unreal is a first-class target, but not the only one
- Pipelines with custom or in-house engines can treat Natsura as a standardised authoring layer, just like other Houdini-based tools
6. Building your own vegetation library
SpeedTree’s built-in library and marketplace are a big part of its appeal, and that model works for many teams.
Natsura optimises for teams that want to own their library:
- Recipes built from Grow, Split, Switch, and Decorations can express entire species, families, and biomes, not just individual meshes
- From one setup, you can generate a range of trees: young → mature, sparse → dense, stressed → healthy, realistic → stylised
- Because the toolkit is open and modular, you can keep evolving that library in-house as projects and art styles change
Licensing is set up to support that:
- On paid tiers, the assets you export with Natsura (“Customer Assets”) are your assets – you can use them in games, film, client work, and sell them as 3D models, under a clear, published EULA
- There’s a plain-language summary at the top of the EULA so production, legal, and artists can get on the same page quickly
The focus isn’t “more pre-made trees than anyone else”. It’s making it much easier for a studio to build, maintain, and own a high-quality vegetation library on top of a strong engine.
7. Engine, not just plugin – and part of an ecosystem
Houdini already has a healthy ecosystem of foliage and environment tools: SideFX Labs, scattering frameworks, other plant plugins, in-house HDAs. Teams will continue to mix them.
Natsura is built to join that ecosystem, not replace it.
Internally, it behaves like a specialised growth engine:
- A large set of Wrappers for everyday work by artists
- A corresponding set of Core nodes – minimal verbs like
grow_core,repeat_core,split_core,switch_core,wrangle_core– for technical artists and pipeline developers - A single Simulate node that executes the graph, resolves mappings and effectors, and applies Decorations
Because Natsura is a collection of SOP nodes and HDAs that respect Houdini’s usual rules:
- It plays well with Labs tools, scattering systems, terrain setups, other foliage HDAs, and your own in-house operators
- You can use Natsura for growth and structural logic, and still bring in other tools for scattering, layout, shading, or niche workflows
- Buying Natsura doesn’t mean you have to stop using anything else – it gives you a deeper foundation to plug those things into
For a studio, you’re not choosing between “Natsura or the rest of the Houdini ecosystem”. You’re choosing to make Natsura the growth and structure engine that sits alongside, and underneath, the rest of your Houdini-based environment tools.
8. Who Natsura is (and isn’t) for
Natsura is likely a good fit if:
- Houdini is already part of your pipeline, or you plan to make it one
- You want vegetation to share the same procedural “brain” as layout, FX, simulation, and world-building
- You care about ecosystems and libraries, not only individual hero trees
- You want the option to go from modelling-style control to simulation-driven behaviour within the same tool, as projects demand
- You value owning and extending your own vegetation framework over the long term
Traditional tools like SpeedTree will probably remain a better fit if:
- You want a standalone app
- You mostly rely on a fixed library you rarely touch
- You prefer to minimise engagement with procedural workflows
If you’re looking for a Houdini-native growth engine, an open node toolkit, and a path to modern Nanite-ready, engine-agnostic vegetation pipelines, Natsura is aimed at you.
9. Where Natsura is today
Natsura 0.5 is an Early Access release:
- The underlying engine, node system, and simulation model have been iterated on over several years
- The toolkit is already being used by early-adopter studios in production contexts
- Some areas (advanced conditional logic, certain mapping workflows, more effectors) are still evolving
This is the phase where early movers can:
- Shift away from purely standalone vegetation tools
- Start consolidating foliage pipelines around Houdini + Natsura
- Influence how the artist-facing tooling evolves