For those who don’t know the tool: Natsura, the Houdini foliage toolkit lives inside Houdini, can push assets to Unreal Engine workflows, and now leans harder into assemblies, mapping, and export glue.

What shipped in 0.6

Version 0.6.0.0 landed on March 25, 2026, with support for Houdini 20.5 and Houdini 21.0. The release calls out modular effectors, Nanite assemblies, an assembly decorator, a revamped UI, analytics, scan extension, and Houdini 21 support. The update introduces an Assembly workflow aimed at quickly rigging twig and branch libraries and assembling canopies. There is also a set of tools for Unreal Nanite skeletal assembly support, paired with wind authoring tools. Assembly-related nodes are flagged as experimental in the release notes, though. Be careful.

On the shaping side, the release adds a modular effector system like a bolt on simulation modifiers with no VEX required. Effectors are an extendable stack, and the base effector node supports writing VEX to extend the simulation and respond to geometry and inputs.

Assemblies, decorators, and Unreal export

The release adds new nodes for an assembly pipeline, including an assembly resource node for mesh library import and auto rigging, an assembly decoration node for canopy decoration that can pick modules based on traits and transform instance hierarchies with rigid rotations, and a classify node for trait-based module classification.

Export to Unreal related workflows gets multiple mentions. The export node for Unreal Nanite assembly lists updates including material support, skeletal and static assembly, fixed instance naming, and removal of a transform on points that broke instancing. There is also a LOP node for USD workflows that creates a Nanite assembly for SOP based creation.

Wind support is expanded through new nodes for wind initialisation and validation, wind class assignment for Unreal, a wind preview visualisation tool that is functional but not accurate or meant to look good, and a node that exports UE5 DynamicWindSkeletalData as JSON. If your environment team already has a wind data convention, this is the part to validate early, especially around naming, material binding, and what your in-engine tooling expects.

Effectors, guides, and growth controls

Several new effectors are listed: deflection, magnet attraction, gravitropism, gravity, and noise based growth perturbation. The grow node line gets a long set of updates in this release, including a new spiral parameter with absolute and relative modes, integration with the effector stack, and an updated decorator stack format to match the effector stack.

One practical change is the way mapping and prim construction are described. Map prim construction is deferred to grow, which is described as reducing node count and compile time. There is also an instant colour preview mentioned, plus options for skeleton swapping and custom draw modules. Growth workflows appear to be treated as a family of versions, with backwards compatibility restored across multiple grow versions and various mapping and parameter warning cleanups.

Rig simplification and reskinning

Rig simplification tooling shows up both as a new simplify rig node and as updates to a simplify rig reskin path, as well as multi stem tree support, chaining of simplify nodes, and added carve method and max joints count. If your pipeline needs a predictable joint budget for game ready trees, this is where you will want to spend time.

Analytics and privacy details

Analytics is “opt-in” and disabled by default, with no data collected without explicit user consent. If you work in an environment with strict compliance rules, the opt in default and EU cloud note are helpful details, but you still need to run your own review. Make sure your team knows what is allowed, and that tool telemetry decisions match your facility policy.

The notes also state that 0.7 will be a breaking release, and this 0.6 release includes precursor work such as a standardised mapping architecture, groundwork for decorator cook trigger decoupling, and a foundation for mappable decorator parameters. Read that as a warning to keep a rollback plan, and to budget time for update testing before you touch active porudction setups.

Compatibility notes for Houdini artists

Houdini 21 support is obvious, including mention of an APEX graph schema enforcement fix. The release also claims continued full Houdini 20.5 support, plus compatibility work around Qt bindings.

In practice, this release spans a lot of surface area: SOP level nodes, UI panels, export to Unreal, USD workflow hooks, analytics, and a mapping engine refactor. That is a lot of moving parts for a minor release number, even if the changelog is transparent about what is experimental. Treat the upgrade like you would any node library update: keep a copy of old scenes, validate the graphs, and test exports end to end before shipping anything client facing.

https://www.natsura.com/

The post Natsura 0.6 adds effectors and Nanite export for Houdini Foliage first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Houdini users can now play chess directly in the viewport, courtesy of technical artist Mohamad Salame. The interactive chess tool relies entirely on VEX scripting for move logic and game state tracking. That means no simulation nodes, no rendering pipelines, and certainly no Python backdoors. It’s all handled inside Houdini’s SOP (Surface Operator) context, with every rule of chess implemented as raw VEX code. If you lose, don’t blame your renderer.

Learning Tool or Just Fun? Yes.

While not meant for production (unless your project is a very confusing FX-heavy Queen’s Gambit remake), the project highlights how logic systems and user interaction can be prototyped in Houdini using just VEX. Think of it as a conceptual playground rather than a feature request for SideFX.

Where to Download

The Houdini chess tool is available for free on Gumroad. No license fees, no royalties – just 64 squares of procedural decision-making. If you’re wondering whether chess belongs in your postproduction pipeline, the answer is: probably not. But if you’re curious how far VEX can be pushed for interactive logic and UI inside Houdini, this checkered curiosity might be worth a look. Or at least a quick match between caching sessions. Check before use, especially if your studio’s pipeline doesn’t include en passant.

The post Pawn to VEX: Chess Comes to Houdini’s Viewport first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

There is always a greater or lesser deposition of organic and inorganic substances in our oceans. This includes, for example, the calcium carbonate shells of diatoms, dead plankton and everything that marine life emits. This continuous shower of material is called marine snow, or ocean dandruff.

The idea of writing a VEX programme for Houdini that simulates the movement of marine snow in the ocean came to me during an exciting presentation at FMX 2024 in Stuttgart. Weta had presented just such a model there, but without going into details or even revealing anything about the code. In the end, it was only clear that the script runs in Houdini.

I have programming experience, but hardly in the simulation area and mainly in Python. So far I had mainly written batch tools, i.e. programmes that execute repetitive processes, e.g. creating shaders, importing assets, etc. The Marine Snow project seemed manageable to me and a good start to do something in the simulation area. So, let’s dive in!

Every beginning is difficult

Ultimately, the big question is always how and where do you start? Apart from the slowly fading memory of the Weta lecture, I had almost no clues as to how the movement of particles could be represented in a physically plausible way. The fact that the simulation was to run in Houdini’s POP solver was almost all I knew at that point. At least the POP system provides a number of ready-made nodes that can be used to transfer forces to particles. Probably the most common example of such a force is gravity, which can be represented with a POP Force DOP. This was once an idea, but it quickly became apparent that POP Force is not flexible enough. Some things can only be solved properly using a script.

So I started by looking for references. What video material was available from which the basic features of the movement or patterns could possibly be derived? Research also involves reading scientific papers. Even if you don’t understand the maths or only have a rudimentary understanding of it, you can often find valuable approaches in the accompanying texts and descriptions. There was film footage of Marine Snow, but no papers that would have helped me. (Here is a link to a video from NOAA, showing a red squid on the ocean, in a “storm” of marine snow. Have a look at the other results from this Expedition, it is amazing and as usual with Deep Sea Science, quite alien. ).

The number of hits for videos was manageable, but sufficient to formulate some assumptions.

1. There are two determining forces: gravity and buoyancy.
2. The wave motion at the surface amplifies the cyclical up and down motion.
3. The particles have different sizes and densities, which influences the buoyancy.
4. New particles are constantly formed and enter the system. Other particles are deposited on the seabed and are thus removed from the system.
5. The particles are in a medium with a certain viscosity (water).
6. Turbulent currents cause swirls and sideways movements.

So how do we get started? What factors should you take into account and what can you try to formulate later? I found it easiest to simulate the forces mentioned in point 1, i.e. the interplay between gravity and buoyancy. Many people will probably remember the formula below from their school days, as it is one of the fundamental equations of Newtonian physics:

F = m * a

The force acting on a particle is the product of its mass and acceleration. For the force of attraction (“gravitation”), acceleration is a constant that is characteristic of every body. Here, on Earth, the constant is not called a, but g and has a value of around 9.81 m/s². In physics, the mass is given in [kg]. The force is therefore a compound unit and is called Newton [N].

(1) gravity = particle mass in kg * 9.81 m/s2

The equation may seem trivial, but it is of great importance for a script because it already represents a calculation rule. For the buoyancy, however, I had to use the search engine I trust and it spit out Archimedes’ law of buoyancy.

(2) buoyancy = density of water * particle volume * 9.81 m/s2

The factor 9.81 again corresponds to g from the gravitational force. The particle volume can be approximated as a sphere. For a sphere, a collection of formulae says that the

(3) particle volume = 4/3 * PI * particle radius3

The particle mass can now also be derived:

(4) particle mass = density of the particle * particle volume

Before we can start calculating the forces, we first need particles. This is done using a small standard mesh that generates points in a cuboid. These particles in turn are sent to a POP solver, inside which a POP Wrangle performs the necessary calculations. In addition to the POP Wrangle, the interior of the solver also contains a POP Kill Node. A complete description of the network can be found here.(→ see POP Up)

It is also important to define start values. Their size and dimension ultimately determine the behaviour of the particles just as much as the calculations themselves.

// Initial variables
float g = 9.81; // Gravitational acceleration in m/s^2
float radius_p = 0.005; // Particle radius in m
float rho_p = 1050.0; // Particle density in kg/m^3
float rho_f = 1030.0; // Fluid density in kg/m^3, e.g. water

To begin with, the script should determine the particle volume and mass, as these values are then used in the formulae. Equations (3) and (4) therefore result in

// Intitial calculations
float volume_p = (4.0 / 3.0) * M_PI * pow(radius_p, 3);
float mass_p = rho_p * volume_p;

The constant M_PI is the circle number, which is predefined in VEX with sufficient accuracy.

Both forces, i.e. gravity (gravity_force) and buoyancy (buoyancy_force), are vectors, but they only act in the Y direction. Gravity always acts downwards towards the centre of mass, while buoyancy counteracts this force. A standard vector in VEX consists of three components, which here represent the XYZ coordinates.

// Calculate force components
vector gravity_force = mass_p * set(0, -g, 0);
vector bouyancy_force = set(0, (rho_f * volume_p - mass_p) * g, 0);

This corresponds to the formulae defined at the beginning with one small exception. With buoyancy_force, the mass is again subtracted in the brackets to obtain the net buoyancy force. This is particularly relevant if a particle’s density is greater than the density of the liquid. This simulates sinking, as the weight force is greater than the buoyancy.

The post Marine-Snow-Simulation in Houdini first appeared on DIGITAL PRODUCTION and was written by Thomas Schlick.

Houdini can read in external data in various ways. The most comprehensive is certainly a self-written Python parser, but that is not necessary here, because Houdini comes with the Table Import Node as standard. This makes it possible to import tables in CSV format. If you look under the bonnet of the table import node, you will of course find a Python script there anyway. This is one of the reasons why I like Houdini so much: almost everything is open and can be studied or adapted to your own needs.

Import

The CSV format contains values that are separated by commas (CSV = comma separated values). These can be words or numbers. Most spreadsheet programmes can save or export tables as CSV. I use Google Sheets here, and it works great: the table import node initially only creates points, which then contain these values in attributes. I use the attributes:

@word, @pscale, @font.

@word gets the values from column A, which is the first column. In Houdini, counting usually starts with zero, hence Column Number 0. The attribute type is a string.

@pscale is a special attribute specified by Houdini. @pscale stands for Point Scale, i.e. the size of a point. This is Column Number 1, and the type in this case is a float, i.e. a floating point number. I could therefore also have entered 1.5 or 2.3 as values in the table.

i have defined @font as type integer, i.e. as an integer. As I want to use three different fonts, I have entered 0, 1 or 2 as values in the table.

The Table Import can also translate (e.g. Lat/Long to Sphere), but the Translator is not needed here.

The second node is Enumerate. This creates an @index attribute with which the points are counted in order to be able to assign them later. The group type must be changed from “Primitives” to “Points”. The next two nodes are not absolutely necessary, but as I wanted to create other sizes and these should be somewhat random, I first used Attribute Expression to convert the @pscale values 1,2,3 into 1.5, 2 and 2.5. To do this, “Custom” must be entered in the node attribute and “pscale” as the name and “Float” for the type. I use the VEXpression for this: “1 self * .5”.
And of course, I could have entered these values in the table straight away, but I didn’t. The zero named here as “OUT_points_with_attributes” is not necessary for the function, but is part of good style.

Loop it!

Now the first loop comes into play. This is a For Each Point loop. It contains 3 font nodes, one for each font. Firstly, I created a font node for this and added the spare input required later. To do this, click on the cogwheel and select “Add Spare Input”.

This font node was then referenced twice using drag-and-drop with the Shift, Ctrl and Alt keys held down. For the copies, I then held down the Shift and Ctrl keys and clicked on Font to remove the reference link. Alternatively, this can also be done with the right mouse button menu and “Delete Channels”.

Fonts

The most important node when it comes to text is of course the font node. It can generate both polygons and Bezier curves or both at the same time. I use polygons here. I have set the level of detail to 4 so that the tessellation is nice and fine.

Working with Bezier curves is also great, but unfortunately not useful here, as the UV layout node used later cannot process them. Now it gets a little more magical or technical. In the “Spare Input0” parameter, the “../foreach_begin1” node is referenced by drag-and-drop or, if you want and like typing, you can do that too. The text to be created is normally simply entered in the text field, but we want to read it in from the CSV table, which has already been converted into points. Backticks can be used here to execute code.

The command required here is “points”, whereby it is not about several points, but about string values from points. The “s” at the end stands for “string”. The first spare input is addressed with “-1”. The zero after it is the first point, here it is always just one point anyway, as we are looping over the points. Then “word”, because we want to read the @word attribute. Brackets around it and a backtick and that’s it.

As an aside and for the sake of completeness, “Add Text Attributes” should also be mentioned here. It is not needed here, but is very cool for other text gimmicks. If the box is ticked, the attributes @textindex, which indicates the number of letters in the word, and @textsymbol, which indicates which letter it is, are created for each letter or primitive. However, this is an ASCII value, i.e. a number. “f”, for example, is then 102.

The three font nodes are then connected with a switch that reads the @font attribute. I have also created a spare input for this. This time it is the “point” command and not “points”, as only a number is read out here and not a string. So “point(-1,0, “font”,0)”. In this case, “-1” is again the spare input, “0” is the first point, “font” is the attribute and the last “0” is a necessary argument, which doesn’t really make sense here. However, if we wanted to read out a vector, “0” would be X, “1” would be Y and “2” would be Z. This is also only mentioned here for the sake of completeness.

Copy to points

Okay, Houdini! Now we come to the copy to points node. First of all, some information in passing: This node will change a lot in H18 and make actions like this easier. No matter. Pack and Instance is not needed here. Transform Using Point Orientation is also not required here, but can also be on. Copy Points Attributes is used because we still need @index. So enter “index” under Set/To Primitive. Delete everything else.

Now you should be able to see a bunch of fonts on top of each other. Before, there was nothing to see in the viewport except a dot in the centre, at most. Tip: In the “foreach_end1” node you can set to “Single Pass” for debugging, then only one iteration of the loop is executed. And always keep an eye on the geometry spreadsheet, where you can see the values of attributes.
Now we come to the UV layout node, which is used here to distribute the words in a shape. In the picture, I have coloured the shape green. I have left space for the two logos of DP and DIGITAL PRODUCTION. Connecting this shape to the second input of the UV layout node should not be too complex. Of course, the words with the @index attribute go into the first one.

UVs

The UV layout node normally uses the @island attribute to delimit the UV parts from each other and the @uv attribute for the positions of the vertices on the UV map. Since there are no UV coordinates here at all, we replace “uv” twice with “P”.

in Houdini, @P is the position of the vertices. For Axis Alignment we select “none” and for Island Rotation Step we set “No Rotations”. If you want to create a Word Cloud with rotated words, they should either be rotated beforehand or you should select 90°, for example, so that no words are upside down.

Padding is the distance between the shapes to be distributed, in this case words, and Scale should be set to “Largest Packable”. The “Advan…” settings are also interesting. This must stand for Advanced. There are iterations here. Here the node randomly tries different layouts and then uses the layout with the best space utilisation. However, each iteration takes time, and 4 is sufficient for this purpose. Different layout versions can be generated with “Random Seed”.
That’s it as far as the layout is concerned, but now we want it in 3D. To switch to a so-called Packed Workflow, we need an @name attribute with a string, i.e. text content. At the moment, we only have an @index attribute, and these are numbers. We do this with an attribute wrangle node.

Select “Primitives” under Run Over and enter the following VEXpression: “s@name = sprintf(“%d”, i@index);”. This creates an @name attribute, which then contains the number as a string. For more details on this VEX function, please refer to the Houdini documentation, which would go beyond the scope of this article.

Now the whole thing is packed, i.e. each word is now represented by a point. This is practical because it is now easier to select the words, for example, in order to make manual corrections to the positions. Simply use an Edit Node to do this.

Before or after the edit node, I used an attribute copy node to write the attributes from the beginning @font, @pscale, @word back to the points, which now contain the packed geometry. Again, @index is used to assign the source and target points (Attribute to Match). Only @pscale is actually needed, but never mind. If you want, you could customise this even more variably and select words more easily or, for example, extrude them differently depending on the font.
Now rotate another loop and extrude the words. To do this, create a For-Each Primtive Loop and place an Unpack followed by a Pack Node. A polyextrude is placed in between.

Then either drag and drop the “foreach_begin3” into the spare input created or enter “../foreach_begin3”. I have set the parameter “distance_multiplier” to 0.025.
The magic is in the Distance parameter; enter “point(-1,0, “pscale”,0)*ch(“distance_multiplier”)” enter. Now @pscale is used to control the thickness of the letters. Do not forget to tick the “Output Back” box, otherwise the letter will be open at the back.

Finally, a file node to save the geometry. It can then be integrated into the rendering scene. The outline plate behind the words was also created procedurally, unfortunately no longer part of this article. But this much can be revealed: I converted a geo into a volume, more precisely into an SDF/VDB. Then enlarged it as an SDF or made it thicker. Then “vdbsmooth” and converted it into a mesh. An Intersection Aanalysis followed by Polypath, then Resample, then Fit and Resample again, and the outline is ready.

Outlook

I would also have liked to have written something about splines, i.e. curve modelling and editing. This works very well in Houdini, even if it takes some getting used to. I would also have liked to discuss rounded edges. But I ran out of pages – we’ll just do that in one of the next issues.

The post Blergh! Word Art! In Houdini? first appeared on DIGITAL PRODUCTION and was written by Olaf Finkbeiner.