Decorations

Decorations are Natsura’s post-process meshing layer.

Growth graphs and Simulate give you a clean skeleton of internodes plus attributes.
Decorations take that skeleton and generate the actual renderable geometry – trunks, bark, clusters, proxies, LODs, and so on – using compiled SOP graphs.

Where Decorations fit in the pipeline

A typical Natsura setup has three stages:

1. Build the growth graph
   Use Grow, Split, Repeat, Switch, Wrangle, etc.
   At this point you are defining structure and behaviour, not meshes.
2. Simulate growth
   Simulate evaluates the graph and produces a skeleton (internodes and attributes).
   The result is still “just” a structured plant description.
3. Apply Decorations (post-process)
   During the same Simulate pass, assigned Decorations run their compiled SOP graphs on that skeleton and output geometry.

Growth stays focused on rules and form.
Decorations handle representation.

What a Decoration is

Conceptually, each Decoration is:

• A compiled SOP graph that knows how to turn Natsura internodes + attributes into geometry.
• Both data (its parameters) and process (the SOP network itself).
• A post-process that Simulate calls after growth is resolved.

Key properties:

• Decorations are assigned to Grow nodes (and related graph elements) via sockets.
• Inside the compiled SOP graph you access the skeleton and its attributes (id, parent_id, generation, root_distance, height, custom attributes, etc.) and decide how to mesh.
• Decorations do not explicitly “target generations”, “species” or “biomes” as first-class concepts – you derive whatever distinctions you need from attributes.

Because the SOP graph is compiled and executed under Simulate’s control:

• Natsura can keep evaluation partial and deferred – only the necessary parts of each decorator cook.
• You can encapsulate complex meshing logic behind a single Decoration assignment, keeping the visible graph simple.

Why use Decorations instead of plain SOP networks?

You can always take the skeleton out of Natsura and mesh it in a normal SOP network.
That’s useful for quick experiments or one-offs.

Decorations exist for the cases where you want:

• Consistent execution
  • The decorator’s compiled SOP graph runs under the same execution model as growth.
  • You avoid accidental full recooks and “everything dirties all the time” behaviour on heavy assets.
• Reusability
  • Once a Decoration is set up, you can attach it to multiple recipes and projects without rebuilding the SOP logic.
  • You can think of “meshing as a packaged asset” rather than a local graph each time.
• Separation of concerns
  • Growth graphs remain about internodes and attributes.
  • Meshing and LOD logic live in Decorations instead of creeping back into the growth network as group logic and parallel SOP streams.

Trade-off:

• It usually takes longer to build a good decorator than to hack a one-off SOP chain.
• In return, you get optimal execution from Natsura’s systems, drag-and-drop meshing, and the ability to treat meshing as part of your procedural Natsura graphs, not an afterthought.

Built-in decorators (high-level)

This section is deliberately high-level. Individual decorators are documented on their own pages.

Trunk / surface decorators

Surface-style decorators generate continuous bark and trunk surfaces from the skeleton:

• Take simulated internodes and attributes as input.
• Produce watertight trunk and branch geometry.
• Use heightmaps, scan data or procedural detail.

Some trunk decorators can also feed back into simulation:

• For example, a trunk decorator can turn a scanned hero trunk into watertight geometry that is then reused as input to another Natsura simulation (extending roots, adding upper canopy, etc.).

This “decorate → resimulate” loop is an advanced workflow and will be expanded and documented separately.

Cluster decorator

The cluster decorator attaches and bends cluster assets (branch chunks, leaf bunches, fronds, etc.) along the simulated skeleton.

• It uses instancing and deformation along internode paths.
• It is designed to be very fast on dense assets when driven by Simulate.
• It is suitable for high-detail crowns, undergrowth and similar dense foliage.

Internally, it’s effectively a “path deform” system specialised for foliage clusters, wrapped as a compiled SOP graph.

Other decorators and future additions

The library is intentionally small and focused right now:

• Generic decorators (surface / trunk, cluster, scan-related flows) are the starting point.
• More generic and more specialised decorators (e.g. dedicated leaf workflows, card/atlas helpers, collision shells) will be added over time.

Teams can also build their own decorators; patterns and guidelines for that will be provided in separate documentation.

Select Decoration and variation

Decorations themselves do not encode “species”, “biome” or similar concepts.
They simply run where they are assigned and read attributes from the skeleton.

To route to different meshing behaviours, Natsura provides select-style logic:

• A Select Decoration can choose between multiple decorators based on attributes on the skeleton (for example, an integer LOD index or some custom attribute you emit in the growth graph).
• The choice happens during the Simulate pass.
• The selected decorator’s compiled SOP graph then runs for that part of the skeleton.

Typical uses:

• Different meshing behaviours for LODs (dense vs simplified) from the same growth graph.
• Different representations for different pipelines (render, proxy, collision).
• Experimental variants without duplicating the whole recipe.

LODs, collisions, and multiple representations

Because you can assign multiple Decorations and switch between them:

• LOD workflows become straightforward:
  • One decorator stack for high-detail output.
  • One or more simplified stacks for lower LODs.
  • Selection driven by attributes or export context.
• Collision / proxy meshes can be generated in parallel:
  • A decorator for render meshes.
  • A decorator for simple hulls or capsules.
  • Both using the same underlying skeleton and attributes.

You’re free to decide how many representations you need; the important part is that they all derive from the same growth + attribute structure.

Mapping and conditions (current status)

Decoration parameters and logic are not as fully exposed to Mapping and conditional systems as growth nodes yet.

Current state:

• Decoration parameters are not generally mappable through Mapping. Where this changes, individual decorator docs will call it out explicitly.
• Basic routing between decorators is handled via Select Decoration and attributes.
• More advanced conditional behaviour (switching based on more complex rules, time, etc.) is planned but should be treated as work in progress unless specifically documented.

The long-term goal is for key Decoration parameters to integrate with the same attribute-driven model used elsewhere in Natsura; this page will be updated as that happens.

Feedback into simulation and nesting

Decorations are primarily a post-process, but they are not always a hard end to the pipeline:

• Some flows already feed decorated results back into Natsura (e.g. trunk extension: decorate, make watertight, resimulate).
• It is technically possible to run nested Natsura simulations inside a Decoration (e.g. a secondary simulation for ivy or lianas on a host tree), and then decorate those again.

Nested setups are powerful and easy to overcomplicate.
Expect dedicated guides for these cases with concrete recommendations and performance notes.

Typical workflow with Decorations

A simple end-to-end workflow might be:

1. Author and simulate growth
   • Build your recipe with Grow / Split / Repeat / Switch / Wrangle.
   • Run Simulate until you’re satisfied with the skeleton and attributes.
2. Attach one or more decorators
   • Assign a trunk/surface decorator to the main structure.
   • Assign a cluster decorator for volume and fine detail.
   • Optionally assign decorators for collision or alternative representations.
3. Iterate on meshing in isolation
   • Adjust Decoration settings without changing the growth graph.
   • Re-use decorators across other recipes where appropriate.
4. Add LOD / variant logic
   • Use Select Decoration and attributes to route to different decorator stacks for LODs, proxies, or experimental variants.
5. Export or feed back
   • Export the decorated result to your target (Unreal, offline renderer, other DCC).
   • In advanced flows, feed decorated geometry back into Natsura for further simulation.

Next steps

If you want to go further:

• Revisit Simulation to see exactly when Decorations run.
• Check individual decorator docs (surface / trunk, cluster, scan workflows, etc.) for parameter details and examples.
• Watch for upcoming “Custom Decorators” guides if you plan to wrap your own SOP meshing networks as Decorations.