Simulation

Simulation is the engine that brings Natsura's graphs to life. Rather than modelling step by step, it runs a growth-cycle-based process, not splines on splines the way a traditional parametric workflow would. When you build a graph with Grow, Split, Switch, Repeat, and the other core verbs, you're describing the rules of a simulation. You're writing a program, not immediately generating geometry.

A grammar for growth

Natsura brings together a botanical growth simulation, parametric control, and direct control in the viewport. From the start, the growth simulation could not be a black box. It had to be something an artist could see into and shape, a structure that produces the plant rather than a hidden generator you feed numbers to and hope.

So the simulation is built on a small grammar, inspired by L-systems. In an L-system, a handful of simple symbols stand for actions: one symbol steps forward and grows, another starts a branch, and so on. Natsura's core verbs play the same roles, in a form that is node-based and made for artists. Grow extends a stem the way F steps forward in an L-system, Split starts parallel branches the way a branch symbol does, Switch chooses between alternatives, and Repeat wraps a piece of structure for recursion.

You compose these verbs into larger pieces. The simplest graph is a single Grow plugged into a Simulate. The Grow that ships is already a composition: it carries its own recursion using an embedded split, switch, and repeat, so one Grow can describe a whole branching habit. You can build your own compositions the same way, and reuse them as ready-made pieces in other graphs.

The important part: you are never asked to write this grammar by hand. The grammar underpins everything, and the tools are the environment built on top of it. You work in the viewport and on parameters, while the verbs, the mapping, and the effectors are the artist-facing shape of the grammar underneath.

Each verb is described in more detail below:

How it differs from procedural modelling

The graph you work with at the SOP level is a kind of metagraph. It doesn't contain the plant, it generates an Apex graph, and that Apex graph is where the simulation actually takes place. You don't need to think about the Apex graph day to day, but it's the thing being evaluated whenever a tree appears.

Visual pending.

Traditional procedural modelling in Houdini is immediate: every node creates geometry, with attributes you can read, and that geometry flows downstream to the next node, where you run a new program on it. Natsura defers that. You describe the rule set, and the geometry is created in Apex at simulation time.

The point of deferring is not that editing a recipe is cheaper than editing geometry. It is that deferring gives control over how the program is executed. The system gets delayed and partial evaluation, and uses them to keep two things separate that are usually tangled together: the logic that constructs the simulation (the graph structure), and the parameter values fed into it. Because those are separate, you can change parameter values without rebuilding or recompiling the Apex graph, and the system can mimic the process of plant growth rather than only produce a final result.

What happens when you plug a Grow into a Simulate

When you drop a Grow into a Simulate, a few things happen in order:

1. Build. Inside the Simulate, those instructions are assembled into an Apex graph.
2. Compile. At the Invoke Graph, the Apex graph is compiled: the VEX snippets, the graph templates, and the overall graph itself.
3. Evaluate. The compiled graph is evaluated. This is where keeping structure and parameters separate pays off, since variation flows in through mapping and vectors. Conditions inside switch logic are resolved, the wrangles and the pruning run, and geometry is generated step by step over the plant's lifecycle.
4. Decorate. The geometry that comes out of the Invoke is the growing tree skeleton. A decoration step then dresses it, producing the result: a hierarchical mesh of trunks, branches, and leaves, rigged and ready for rendering or export.

The core verbs

These are the atomic building blocks of the grammar. The badges above jump straight to each one. For the full parameter reference on any of them, follow through to its node page from here.

Grow

Defines a growth step: length, angle, width, forking, and recursion. The Grow that ships is already a composition, carrying its own split, switch, and repeat internally, so a single Grow can describe a whole branching habit.

Visual pending.

See the Grow node for its full parameters.

Split

Creates explicit parallel branches in the graph topology, so growth continues down more than one path at once.

Visual pending.

See the Split node.

Switch

Routes growth to different subgraphs based on attribute conditions, for example switching to flowering logic once age passes a threshold.

Visual pending.

See the Switch node.

Repeat

Encapsulates a subgraph between a Repeat Begin and a Repeat End for explicit recursion, so a piece of structure can grow over and over.

Visual pending.

See the Repeat node.

Prune

Removes branches when conditions are met, and re-evaluates over multiple cycles for natural die-back.

Visual pending.

See the Prune node.

Wrangle

Drops down to VEX for custom attribute authoring, gates, and effectors, for when the built-in verbs don't cover what you need.

Visual pending.

See the Wrangle node.

Driving growth: mapping and effectors

Once a graph describes how a plant grows, two systems control the growth in detail. Both are introduced here and covered in depth on their own feature pages.

Mapping. Every parameter in Natsura (a branch angle, a width, a fork probability, the strength of any effector) can be a constant, or a value computed per internode from an attribute. The mapping framework was built so a recipe isn't a fixed set of numbers but a set of relationships: width follows age, fork probability falls toward the tips. That is what lets one graph respond to seeds and attributes and grow a whole species rather than a single tree. You build those relationships with Map chains. See Mapping.

Effectors. Where mapping drives parameters, effectors supply direction. An effector is a per-point vector (gravity, the influence of an ancestor, a placed magnet, a noise field) that growth reads through a response mode to bend the structure. Effectors are how a tree grows up against gravity, echoes its own branching, and responds to where it lives. See Effectors.

For the artist-facing, advanced take on using both to shape a tree, see Shaping.

Endless variation from one graph

Because evaluation is deferred, the same graph can be evaluated many times over with different seed parameters and effectors, producing endless variation. A forest is a hundred different trees, not a hundred copies of one. Because Natsura is a simulation rather than a parameter-tweaking tool, you can build a recipe for a species that responds to its environment and to a handful of high-level attributes, and then grow a whole population from it. What you author stops being a single tree; it becomes an entire species definition, and you are describing how the species grows rather than modelling any individual one. Get the ingredients right and a stand reads as real trees responding to real stimulus, not as instances of one model.

Variation comes from composing several mechanisms, each at a different scale: crude randomness within a tree, attribute-driven difference between trees, trait-based selection within a canopy, and density removal at the end. Plus age, which is really just another attribute driving all of the above.

Visual pending.

Randomness and seeds (within a tree)

The most basic tool is probability: crude, but powerful. Every Grow carries a Seed, and uses it to derive stable per-internode random values; changing the seed reshuffles the result into a new instance with the same statistics. Drive any parameter with a Map Random step for stable per-internode jitter, or layer a low-amplitude Noise Effector for a coherent spatial wobble rather than independent jitter.

Attributes carry the variation (between trees)

This is where Natsura turns into a factory. Feed Simulate a point cloud and each point grows its own tree; the point's id is its per-tree seed, so each tree's random choices differ. But the real leverage is per-point attributes: author age, health, size, vigour, whatever vocabulary describes your library, onto the seed points, then let the recipe express them through Mapping, switches, and wrangles. A taller-on-average attribute produces a taller tree; a higher-age attribute produces a gnarlier one. You are building a description of how an entire species behaves across a range of conditions, not one tree.

Because it's a simulation, trees can also respond to their environment and to each other. See Situation & Environment.

Visual pending.

Trait-based selection (within a canopy)

Variation inside a canopy is handled by the Traits. Think of an n-dimensional space (angle, size, health, anything you like) where the tree's skeleton carries a field of attributes and each classified foliage assembly carries trait values. The decoration distributes assemblies to the spawn points whose traits fit best. Set this up well and you have described how an entire species' foliage should look, not just one tree's. The Classify gizmo is the interactive surface for assigning those traits.

Density-based removal

Recipes tend toward even density; real trees have voids and crowded patches. The Assembly Decoration runs a density-based removal pass after placement: it computes local density and prunes sub-components from over-dense regions, the final layer of variation. (There is also pruning in the core system via Prune; it's rougher at the moment but can drive striking results, because removing parts and letting them regrow produces more aged, realistic structures.)

Age

Age is the most common artistic ask, and in Natsura it's an attribute, not a separate mode. A young tree and an old tree of the same species express themselves completely differently; you reach that difference by driving growth from an age attribute.

• Per-tree age comes from the seed inputs: an age (or years/vigour) attribute on each point scales growth steps, length, width, fork probability, and decoration density, so older trees come out larger and gnarlier.
• Per-branch age comes from the age attribute every internode carries, plus the trait-mapping system in the assembly decoration, so older branches are thicker, droopier, and hold less foliage.
• Losing limbs is handled with pruning (crown retrenchment, dead spires). Pruning isn't in its most accessible form yet, but it's the substrate for veteran-tree silhouettes.

Any parameter, any effector, any switch or condition can be driven by age. As the toolkit grows, more higher-level controls and time-varying attributes are being added so accurate botanical simulations get easier to build.

Visual pending.

The variation stack in practice

1. Seed: each tree uses its input-point id, so a scatter reads as distinct trees.
2. Mapping for shape: width, pitch, fork probability driven by maps that combine attribute reads (u, age) with random jitter.
3. Effectors for direction: gravity plus a low-amplitude noise effector, for regularity and organic wobble together.
4. Trait-driven foliage: the assembly decoration picks library assemblies from per-tree traits.
5. Removal: the density pass thins the canopy where placement got too dense.

No single step is enough; together they produce trees that look like real trees.

To go deeper on the mechanisms that drive variation, see Mapping, Effectors, and Situation & Environment.