Simulation Override

This tutorial covers the simulation Override feature, which should be applied as Pre-Override, i.e. before the Carbon Simulation node.

At first glance, Pre-Override is working similarly to Goal Pose/Goal Skin, as it provides a target/goal for the simulation to achieve on a per frame basis. Goal posing provides the option to set positional constraints via kinematic, constrained or dynamic nodes, using strengths and paint maps. In contrast to that, the Pre-Override only requires a target pose. This override pose must be seen as a suggestion, which the simulation then tries to fulfill. While it is not guaranteed that the target is achieved by the simulation, the result will be physically correct and respect all possible collisions. Therefore, if one wants to work with positional constraints, it is best to refer to Goal Pose. If this is not required, the Pre-Override feature is a very powerful tool which is easy to use and requires little setup.

Most of the applications for the override feature will fall into the following two categories:

  • Interaction with other solvers: The Override provides a safe and easy way to couple the Carbon solver with other solvers in Houdini.
  • Custom Effects: Besides coupling the solver with other solvers in Houdini, the Override feature is a powerful and quick way of adding custom effects by for example using a Houdini Python node or an Houdini Attribute Wrangle node.

This tutorial shows how to use the Pre-Override to create a custom effect which acts like a moving magnet to a stylized grass which is swinging in the wind.

Starting Point

The scenario is built from a basic Carbon Collider, which serves as floor and attachment point to a single Carbon Cloth containing all individual strands of grass. The bottom row of points of each strand is attached to the floor with a Carbon Binding.


Using a bounding box to create the group of points to be bound to the collider.

As shown above, the Group node’s Bounding Box feature allows to quickly select all points of the bottom row of each piece of grass geometry.

To make the strands “move in the wind”, a similar setup to the one seen in the provided example in Carbon Flow is used. After that, add an animated spherical Carbon Collider, that moves within the grass.

Below is a screenshot of the DOP network at this point.


DOP simulation setup before the override.

Magnetic Effect

In this stage, indirectly turn the spherical collider into a magnet. The first step is to change the layout in the DOP network. Add a Multiple Solver node and attach the Carbon Binding to the multisolver’s first input. Then attach a SOP Solver, a Carbon Override, and the Carbon Simulation to the second input to form a simple simulation with override.


Multisolver setup for Pre-Override.

The order in which sopsolver1, Numerion_Carbon_Override1 and Numerion_Carbon_Simulation1 are attached to multisolver1 is very important, as the Pre-Override will not work otherwise.

When a Carbon Override is used after a Carbon Simulation, the Carbon Override node will issue a warning to remind the user that any sort of Post-Override is not robust and can cause corrupted simulation results or worse.


Wrong multisolver input order.


Override warning.


Any Post-Override should be avoided as it will lead to instabilities in most cases. This is due to the nature of the implicit forces generated by the enforced point positions.

Next, double-click on the SOP Solver to edit and create your override network. In this tutorial, all that is needed is a single Attribute Wrangle node.


Attribute Wrangle node.

Inside the attribute wrangle, all points within a certain distance from the center of the animated sphere are moved in the direction of the center of the sphere. This leads to a magnetic effect inside the fall-off zone. Note that it is not necessary to check for collisions here, as this is used within the context of Pre-Override, and the simulation will solve all reasonable collision issues.

The last step in the setup is the Switch node (see screenshot below). A simple script controls which objects are affected by the Pre-Override. Looking back up at the screenshot of DOP simulation setup before the override., the Carbon Cloth node is the third node that gets passed to the Merge node, which then eventually leads into the first input of the Multiple Solver node, and therefore has id 2 (as counting starts at 0).


Override Switch.

The resulting simulation then looks like this:


Final simulation.

SOP Setup

When working solely in the SOP network, all geometry and Carbon nodes can be placed in one single geometry node.


Network for Pre-Override in SOP.

You can see that at this point, the only difference to a normal SOP simulation is that the usual Carbon Simulation node is replaced by a Carbon Simulation Override.


Make sure to keep the Pre-Override parameter toggled on.

Next, double-click on the Carbon Simulation Override to edit the override network.


SOP Pre-Override network and Carbon Objects Geometry node.

Inside the network, place the same Attribute Wrangle node used for the DOP setup between the Carbon Objects Geometry and the Carbon Objects Override nodes.

The Carbon Objects Geometry extracts and unpacks the geometries of up to four different Carbon objects from a SOP Carbon Simulation geometry stream.


Several of these nodes can be used in cascade to extract more than four objects’ geometries by using one of the outputs as a bypass.

In this case, we only need to edit Numerion_Carbon_Cloth1. Use it for Output #2, then connect the second output to the Attribute Wrangle node and then that node to the Carbon Objects Override’s second input.

The Carbon Objects Override node replaces up to three Carbon object’s geometries directly from inside the Carbon Simulation geometry stream, i.e. this where the actual override happens.


  • Several of these nodes can be used in cascade to replace more than three objects’ geometries.
  • These geometries must have the same matching path primitive attribute as the objects’ Carbon geometry they are replacing, as otherwise no replacement operation will happen. Make sure this path primitive attribute (which is automatically generated by the Carbon Objects Geometry node) is not removed in any of the changes made to the geometry.