Building Your Own Decorations

The shipped decorations, Trunk Decoration, Surface Decoration, Clusters Decoration and Assembly Decoration, cover the common meshing cases. When none of them fit, you can author your own on top of Core Decoration, which every shipped decoration is built on.

This is a technical workflow. Decorations are stored and run as compiled SOP networks, which is what makes them portable and cheap to re-evaluate, and it sets rules for what can go inside one. Decorations explains how the system works; this page covers what that means when you build one.

When to build your own

• A meshing approach for an organ none of the shipped decorations handle, such as fruit, thorns, spines or caps.
• A proxy for collision or LODs that needs its own geometry per internode.
• A debug overlay, such as markers, vectors or frames, tied to tree attributes.
• A decoration that reads a project-specific attribute, such as damage or infestation, and meshes accordingly.

If a shipped decoration does the job but at the wrong density or with the wrong settings, change its parameters or map them first. A custom decoration takes more work.

Starting from Core Decoration

Core Decoration is hidden from the Tab menu in 0.7.3, and the toolbar doesn't create one. To place one, open Windows > Hscript Textport and run:

opunhide Sop natsura::core_decoration::1.0

It then shows in the Tab menu until you restart Houdini.

Core Decoration takes the growth graph and returns it with your decoration's instructions added. Nothing is meshed at that point. The Simulate runs the instructions after the skeleton is grown, in the right order and with the right context. Double-click into it and build your network in the editable subnet, meshing/editable: the SOP network that reads the skeleton and its attributes and makes the geometry you need. The rest of the node is the interface to the Natsura system, so leave it as it is.

Natsura only treats a node as a decoration when its Tab menu entry sits directly in a Natsura Decorations submenu, as the shipped ones do in Natsura/Decorations. Core Decoration itself sits under Natsura/Core, so wrap it in an HDA, name it for what it makes, and set the HDA's Tab submenu path to Natsura/Decorations. Natsura reads the list of decorations once per session, so restart Houdini after you first save the HDA. The toolbar's Decorate menu lists only the shipped decorations; assign yours by dragging it into an empty slot under Decorations on the Grow.

The rules

Keep the network attribute-driven. Read attributes from the skeleton, write attributes on your own streams, and let those attributes drive the nodes that do the work.

Use verbs and VEX. Most native Houdini verbs, such as Sweep, Copy to Points and Resample, compile cleanly. Nodes that aren't verbs either won't compile or lose portability, so check whether a verb and some attribute setup can do the same job.

Don't reference node paths. A channel reference such as ../foo/value to a regular SOP breaks when the compiled network is loaded somewhere else.

Read parameters from primitives. To avoid recompiling on every change, decoration parameters reach the network as geometry primitives, not as links to the UI. VEX reads them, with primuv() or the parameter dictionary, and writes the attributes the verbs use. This is the same pattern as Mapping. Changing a parameter only re-evaluates; changing the network's structure recompiles it.

Follow these and the decoration can be saved as geometry, loaded into another scene, and still run.

A Wrangle in the growth graph is a quick way to prototype the attribute logic before it goes into a decoration.

Status

More templates and worked examples are planned. Authoring decorations directly as APEX graphs is also planned; the compiled-execution rules above will still apply where they come from the runtime.