Week 4: Unraveling the Art of Debris Emission in Fracturing Rigid Body Dynamics
This week, I embarked on a fascinating journey, delving deeper into the world of Fracturing Rigid Body Dynamics. My focus? Setting up a system for emitting debris, a crucial element in creating realistic and dynamic visual effects.
Last week, I attempted using a shelf tool to generate debris from the primary fracture, involving larger pieces, and it didn't quite yield the desired outcome. The tool lacked the fine-tuned control I needed and didn't align with my reference.
Undaunted by the challenge, I rolled up my sleeves and delved into some research to craft a manual setup. Here's how it unfolded:
Sourcing the Material:
I started by extracting the inner faces from two previously set up fracture configurations. Next, I scattered a copious number of points, setting the stage for the mathematical magic to come.
According to the wisdom shared by Gabriel Neville, an FX Lead at MPC FILM, the method of sourcing points for debris emission is demonstrated below:
-
This code is responsible for finding neighboring points within a specified maximum distance (MaxDist). It iterates through the list of neighboring points and checks if the point's name (@name) is different from the current point's name. If they are different, it sets the color (@Cd) of the current point to red (1, 0, 0) and assigns the index of the neighboring point to i@neighbourPoint.
Additionally, it calculates the distance between the current point and the neighboring point and stores it in f@distance. If this distance is less than a specified minimum distance (MinDistance), it sets the distance to the MinDistance.
This part is like a detective looking for nearby points. It checks if any points are close to each other. If it finds a point nearby, it marks it as a "neighbor." It also measures how far these points are from each other. If they're too close, it makes sure they're at least a certain distance apart.
-
This code calculates the actual distance between the current point and its neighbor using the previously calculated distance. It then checks if the actual distance is greater than the distance multiplied by a distance multiplier (DistanceMult). If it is, it sets the color to yellow (1, 1, 0) and sets i@active to 1, indicating that this point is active.
Here, it checks if a point is far enough from its neighbor. If it is, it gives the point a special color and says, "Hey, you're active!" Imagine it as giving a high-five to points that are far apart.
-
This sets a specific frame number. In simpler terms, it's like telling the program to remember that on frame 100, something important will happen.
-
Inside a SOP solver, this code checks if the point is active (i@active == 1). If it is, it sets i@activeFrame to the current frame number (@Frame).
Then, it ensures that i@activeFrame does not exceed the activeFrame value of the previous frame by using min().
This is like having a notebook to remember things. It notes sown which frame something became active. It’s saying, “Hey, on this frame, you became important!”
-
If i@activeFrame is not equal to the current frame (@Frame), it removes the current point.
If a point is no longer needed, it's removed from the program.
-
If i@activeFrame is greater than 36, it removes the current point.
If a point has been active for an extended period, it's cleared from the scene.
Particle System Play:
With a plethora of emitting points at my disposal, I fed them into the particle system, generating a generous supply of debris pieces. This step was pivotal in bringing life to the simulation.
Fine-tuning the Concrete Touch:
To add that extra touch of realism, I introduced refined concrete pieces. Employing the same procedural modeling setup that breathed life into my two main fracture RBDs, I infused them with an aesthetic charm, elevating the overall visual appeal.
And here is the result of this week!
