CARBD DUAL-CAR COLLISION TUTORIAL

The new RBD Car Fracture SOP and RBD Car Transform SOP, combined with the existing RBD Car Rig Tools in Houdini, make it quick and easy to set up a working car crash simulation.

This tutorial covers the full process:

• Rigging and driving two cars
• Fracturing them using the new tools
• Simulating collision destruction with the RBD Bullet Solver

We’ll walk through how the HIP file has been set up, helping you understand the workflow so you can either recreate it from scratch or build upon it. For the best experience, keep the HIP file open as you follow along. Click the "Download HIP File" button above to get the project files. With that ready, let’s get started!

STEP 1 - The Setup

It's important to start the rigging process with well-prepared geometry. This includes proper grouping for different parts, clear name attributes, and clean geometry—free of open faces, loose points, or interpenetrating meshes. While the RBD Car Fracture SOP can handle some topology issues, it's recommended to clean and prep the geometry for optimal results. Open the GEO_car_asset geometry node to view the car asset used in this project.

In this case, the car model already has proper groups, normals, UVs and a @name attribute. Generally, since the @name attribute will be overridden while fracturing the geometry, we would want to copy the original name attribute under a different attribute name or as a @path attribute to assign materials in Solaris. Fortunately, we have an existing @shop_materialpath attribute here that can be renamed to @path for the same purpose. Some additional steps include coloring parts of the wheels to better visualize their rotation and correcting the car body’s UV maps for later use while texturing in Copernicus. With that, we're ready to begin rigging.

STEP 2 - Rig and Drive

Once the car and ramps are set up, we can begin rigging the car. In this example, the same car model is used twice, but the setup works just as easily for simulating multiple cars. Let’s dive into SIM_car_driving to see how it's set up.

The RBD Car Rig SOP controls the driving parameters, while the RBDxform SOP sets the car's start position after rigging. We begin by assigning the Wheels Group and Steering Wheel Group in the car rig, and then animate the Steer, Speed, Brake, and Hand Brake parameters to shape the drive simulation. For more accurate results, we will configure additional settings such as Center of Mass, Acceleration Profile, Tire Friction, Wheel Scale, Suspension, and Density. Since both cars are identical except for the animated elements, all the parameters remain the same for each.

The cars are packed using RBD Pack SOP before merging, and then separated with RBD Unpack SOP by enabling "Enforce Unique Name Attribute per Instance" and using the @index attribute. This ensures each car has a unique name attribute, which is essential for the Bullet Solver to distinguish between them.

Additionally, the @restxform attribute is output from the RBD Bullet Solver to transform the fractured geometry with the simulation points down the line.

In this setup, the ground plane is a heightfield that includes both the ramp and terrain. It’s prepared in the GEO_procedural_ramp geometry node and assigned as the collision object under the Collision tab in the RBD Bullet Solver.

STEP 3 - Fracturing

This is where most of the work will happen—but all within a single node. Inside the SIM_car_fracture, the same car used in the driving simulation, with the same RBD Car Rig (without any keyframes), is connected to a new RBD Car Fracture SOP. This preserves not only the names and constraints generated by the rig—crucial for the following simulation—but also key properties like Center of Mass, Tire Friction, Wheel Scale, Suspension, and Density, ensuring consistency throughout the setup.

We use separate Car Rigs to keep the driving and fracturing processes independent. This makes it easier to iterate on the driving—tweaking parameters like Speed or Steer—without needing to re-fracture the car each time. However, if significant changes are made to attributes such as Wheel Scale or Center of Mass, it's important to update this Car Rig and re-fracture the car to maintain accurate simulation results.

Next, the process becomes straightforward in the Sections tab. We will assign different parts of the car to separate sections for independent control over the fracture type (metal, glass, wood, rubber). Aside from adding Edge Detail, enabling Proxy to Geometry provides an additional fracturing layer with varied fragment sizes. Constraint attributes like Strength Scale, Stiffness Scale, and Angular Stiffness Scale can also be adjusted per section but we're leaving them at default for now.

There is also a checkbox for enabling Constraint to Neighbor Sections. When enabled, it automatically links nearby sections using glue constraints. It’s best to turn this off for parts like doors, hoods, or trunks that require manual constraint setups, such as hinge constraints. For metal, we'll use the Sheet model since these parts are planar geometry rather than solid objects. Despite being planar, the RBD Car Fracture SOP extrudes the planes and converts them into solid objects when creating proxies. This extrusion can be controlled by the Thickness parameter.

Additionally, you can control the Section Connector Constraints and global Constraint Attributes. The Strength Scale, Stiffness Scale, and Plastic Hardening Scale here affect all constraints between pieces and sections collectively. Since the suspension comes from the Car Rig, the Suspension Stiffness Scale can also be adjusted here, without needing to return to the rig each time. The values shown here were finalized after multiple test iterations, before caching the fractured car.

These constraint values can be adjusted at this stage or later using a separate RBD Constraints Properties SOP before the simulation. In this project we will do both. The Strength Scale, Stiffness Scale, and Plastic Hardening Scale is reduced significantly due to the high Constraint Iterations setting on the RBD Bullet Solver. With more iterations, constraints become harder to break unless their glue strengths are significantly reduced. This is where the global parameters become especially useful—they let us fine-tune all constraints across sections without having to adjust each one manually, streamlining the workflow compared to older methods.

We will enable Disable Motors to stop the cars from running after the crash, and turn on Retarget Anchors and assign the front wheel groups so that they break apart with the front suspension upon impact. This is necessary in this case because we’re dealing with a frontal collision, and parts of the front suspension are expected to break. Without retargeting, the wheels might remain attached to nothing, which looks unnatural. When retargeting is enabled, constraint anchors that were previously attached to the 'body' (the Chassis Group) are reassigned to the nearest fractured piece—since those pieces are no longer labeled 'body' . This allows the wheels to detach along with the broken front suspension and axle.

To optimize performance, Poly Reduce Proxy Geometry is enabled by default but we will disable it to avoid any volume loss errors that might occur, especially with smaller pieces. Compute Collision Padding can be adjusted here or in the Bullet Solver, and also helps prevent the same issue.

By default, Match Input Density is enabled to match the car’s weight as defined in the Car Rig. However, you can disable it and manually adjust the weight here if needed, without going back to the Car Rig. We shall leave it as is because the existing weight works just fine.

Here’s how the initial fracture looks after all these settings are applied.

After the custom fractures and constraints are set, now is the time cache the car geometry using an RBD IO SOP. This way we can retain a single fractured version of the car while freely adjusting the drive simulation. Since the fracture setup is independent of the drive, we have the ability to iterate on the fracture after testing it in the crash simulation, as done in this case.

STEP 4 - Crash Simulation

As mentioned earlier, the Car Fracture SOP allows you to build further on the existing setup. At this stage, we have one fractured car and two unique sets of drive simulation points with the @restxform attribute and drive simulation data. Using the new RBD Car Transform SOP, we can drive the fractured car using these simulation points. Open the SIM_car_crash geometry node to follow along.

After unpacking, we'll modify constraint properties common to both cars. In this case, the following adjustments have been made:

• Glue strength has been increased on the wheel constraints.
• Angular damping  has been adjusted on the soft constraints of the tires.
• Constraints of the windshield have been redefined.
• Angular properties of the hood and trunk door constraints have been tweaked.
• Strength of the Section Connector Constraints and window constraints has been increased.

(All these adjustments are specific to this setup and were refined through multiple iterations of the crash simulation.)

Right before simulation, the cars are split and frozen at frame 1 using a Timeshift SOP. These will later be used in the RBD Car Deform as reference inputs for deformation.

Separately, both cars are also frozen at the simulation's start frame to be cached as high-res geometry, which will be transformed using the Transform Pieces SOP with the simulation points. Why? Because we have points with unique name attributes corresponding to the name of each piece. This approach reduces the need to cache heavy geometry to disk.

Since constraints cannot be transformed like geometry--because we are setting them up for deletion on the Bullet Solver--they must be cached separately alongside the simulation points. Retiming the simulation for slow motion is a requirement, so it is we will cache more substeps to disk for better accuracy.

Most of the key work happens under the Constraints tab on the RBD Bullet Solver. Here, we'll select constraint groups using the @constraint_tag attribute and delete the constraints either based on a threshold or at a specific frame. This gives us fine control over how the cars break apart, allowing for more art-directed destruction.

For example, in the image above on the right, all metal constraints—which are soft constraints—are selected and set to be deleted beyond a threshold of 0.055, causing impacted pieces to break off and fly apart, adding a more dynamic feel to the simulation. You can explore all the tabs under Break Thresholds to see how these are configured—it’s all fairly straightforward.

Beyond that, several other parameters help improve the simulation:

• Constraint Iterations have been significantly increased.
• Collision Padding is set for both piece-to-piece and geometry-to-collision interactions.
• Drag is enabled to help stabilize the motion.
• Randomize Constraint Order is turned on to improve stability.

A common issue with simulating very small pieces is that they don’t settle easily and continue to jitter. This happens because their mass is extremely low—well below 0.1. To address this, we read the computed @mass and @v of each piece on every frame using a SOP Solver within the RBD Bullet Solver. Using an Attribute Wrangle, we multiply the @v (velocity) by 0.96 and @w (angular velocity) by 0.84 to gradually reduce the movement if a piece has @mass less than 0.1 and @v less than 1. Additionally, we start a @timer for these pieces, and if the timer exceeds a value of 24, we deactivate the piece entirely so it no longer moves.

When it comes to caching the simulation, we will only cache the simulation points and the constraints with 10 substeps each. Since we have already saved the static fractured cars to disk, we can use these simulation points with the Transform Pieces SOP to transform the fractured cars. But why do we need to cache substeps? This will be explained shortly before which we will take a look at the FARM_cache TOP on the object level. 

This TOP setup was used to run all simulation caches using the render farm. This is an efficient way of running multiple simulations while still continuing to work on the current file. If there isn't a farm to leverage, this PDG setup can still be run using the Local Schedular. Additionally, you have the option of setting up wedges for any of the parameters you want to iterate on. Although this hasn't been done here, it is an option you could try at your own convenience. 

STEP 5 - Retime and Deformations

The deformation process has been significantly simplified. The RBD Deform Pieces SOP and the RBD Car Deform SOP are the two main nodes to focus on. However, before deforming, we need a slow-motion version of the cars for the final output, so it’s wise to use the Retime SOP before deforming the geometry.

After splitting the two cars into separate streams, we can perform individual deformation operations. This allows for manual adjustments to each car, such as post-impact animations. Let's dive into the POST_car_deformation geometry node to take a look.

The RBD Deform Pieces SOP requires three inputs: geometry, constraints, and proxy geometry. The Group must be set using the @name attributes created during the fracturing stage. Since we only need to deform metals and rubbers, it's best to have named the parts accordingly (e.g., metalxyz, rubberabc, etc.) on the Car Fracture SOP itself. Set the Group Type to Points, and the Boundary Connection to Cluster Attribute and Constraints. This ensures that pieces with deleted constraints don’t remain deformed but instead break apart correctly. Set the Cluster Attribute to @parentpiece. Finally, for the RBD Car Deform SOP, use the reference geometry output from before the crash simulation as the second input.

Make sure to set the Chassis Base Group on the RBD Car Deform SOP to @name=body-(@index) based on the index of your car, in this case 0 or 1.

After unpacking the output geometry, we need to use the RBD Disconnected Faces SOP to re-enable the @oppositefacename attribute and also create a @disconnected attribute. This allows us to delete the inside faces based on that attribute and also use it to scatter points on the inside faces for sourcing glass debris.

All that’s left is to use the simulation geometry to source and simulate secondary effects like glass debris, glass dust, car dust, ground impact dust, and tire trail dust. This HIP file contains some intermediate-level setups for these secondary simulations. These setups are reusable and can be simplified or expanded into more complex versions based on your needs.

While this tutorial focuses on the destruction effects, the file also includes a Solaris setup. This covers assigning materials to the cars and secondary sims, adjusting textures using Copernicus, setting up wedges for different scene cameras, rendering layers, and compositing them in Copernicus. Feel free to explore the file—break it down, study it, or rebuild it from scratch.