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 setting up the example HIP file, 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 and a name attribute. It's recommended to copy the name attribute and rename it to @path, which will be useful for applying textures later in Solaris. Fortunately, we also have an existing @shop_materialpath attribute 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 use later during 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. Begin by assigning the Wheels Group and Steering Wheel Group in the car rig, then animate the Steer, Speed, Brake, and Hand Brake parameters to shape the drive simulation. For more accurate results, 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 output from the Bullet Solver is required 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 happens—but all within a single node. Inside the SIM_car_fracture, he same car used in the driving simulation, with the same RBD Car Rig (but 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 a separate Car Rig 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. You can 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, Proxy to Geometry can be enabled for 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.

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 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. Parameters like Strength Scale, Stiffness Scale, and Plastic Hardening Scale 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 were finalized after multiple test iterations, just 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. The reason for using extremely low values for Strength Scale, Stiffness Scale, and Plastic Hardening Scale is 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.

It’s important to enable Disable Motors if you want the car to stop running after the crash, and to turn on Retarget Anchors for the wheels so 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, you can reduce the poly count of the proxy geometry for a lighter simulation, or keep it detailed to preserve smaller fragments. Disabling Poly Reduce Proxy Geometry can also help avoid volume loss errors, especially with smaller pieces. Compute Collision Padding can be adjusted here or in the Bullet Solver, which 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.

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

After all the custom fractures and constraints, it’s a good idea to cache the car geometry using an RBD IO SOP. This lets you retain a single fractured version of the car while freely adjusting the drive simulation. Since the fracture setup is independent of the drive, you can also iterate on the fracture after testing it in the crash simulation, as done in this case. Don't forget to cache the re-fractured car when making major changes to the Car Rig as mentioned before. 

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 sets of car 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, since the original body and wheel name attributes from the RBD Car Rig are still intact. Open the SIM_car_crash geometry node to follow along.

After unpacking, you can modify constraint properties shared by both cars. In this case, the following adjustments have been made:

• Glue strength increased on the wheel constraints.
• Angular damping adjusted on the soft constraints of the tires.
• Constraints of the windshield redefined.
• Angular properties of the hood and trunk door constraints tweaked.
• Strength of the Section Connector Constraints and window constraints 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 are later used in the RBD Car Deform as reference inputs for deformation.

Separately, both cars are also frozen at the simulation's start frame to serve 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 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 advisable to cache more substeps to disk for better accuracy in this case.

Most of the key work happens under the Constraints tab on the RBD Bullet Solver. Here, constraint groups are selected using the @constraint_tag attribute and deleted either based on a threshold or at a specific frame. This gives you 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 solver 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 velocity of each piece every frame using a SOP Solver within the RBD Bullet Solver. Using an Attribute Wrangle, we multiply the velocity by 0.96 to gradually reduce the movement if a piece has a mass less than 0.1 and velocity less than 1. Additionally, we start a timer for these pieces, and if the timer exceeds 24 frames, we deactivate the piece entirely so it no longer moves.

After this, you can either set up a TOP network—such as the FARM_cache TOP shown on the geometry level—to procedurally simulate all the caches, or just cache each simulation to disk manually. You can also go one step further and create wedges for any of the parameters you want to iterate on. Now we'll open the POST_retime_for_slomo geometry node to see how to retime the RBD simulation.

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 beforehand.

After retiming, we can split the two cars into separate streams to perform individual deformation operations. This allows for manual adjustments to each car, such as post-impact animations.

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 name the parts accordingly (e.g., metalxyz, rubberabc, etc.). 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 just 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 all secondary effects, such as glass debris, glass dust, car dust, ground impact dust, and tire trail dust. You can download the HIP file to explore some intermediate-level setups for the secondary simulations. These setups are reusable and can either be broken down into simpler versions or expanded into more complex simulations, depending on your needs.