Week 06: Basic Structure of Rigid Body Dynamic Simulation
March 1, 2024
In this week's update, I've established the foundational structure of the Destruction Rigid Body Dynamics, comprising the primary fracture RBD, debris, and small particles.
I. Debris and Particles Sourcing
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 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.
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.
To optimize the render, I used LOP Instancer to assign these pieces into Solaris with random sizes at random points to create the variety.
II. Particles
Using the same Particle System of Debris, I sorted out the 95% amount of point to make them into tiny particles to polish the shot. These particles did not have any instance geometry on them, and their appearance is driven by pscale only.