# Simulate Tearable Cloth and Ragdolls With Simple Verlet Integration

Difficulty:IntermediateLength:LongLanguages:

Soft body dynamics is about simulating realistic deformable objects. We'll use it here to simulate a tearable cloth curtain and a set of ragdolls that you can interact with and fling around the screen. It'll be fast, stable, and simple enough to do with high school level mathematics.

Note: Although this tutorial is written in Processing and compiled with Java, you should be able to use the same techniques and concepts in almost any game development environment.

## Final Result Preview

In this demo, you can see a big curtain (showing off the fabric simulation), and a number of little stickmen (showing off the ragdoll simulation):

You can try the demo yourself, too. Click and drag to interact, press 'R' to reset, and hit 'G' to toggle the gravity.

## Step 1: A Point and Its Motion

The building blocks of our game with be the Point. For the sake of avoiding ambiguity, we'll call it the `PointMass`. The details are in the name: it's a point in space, and it represents an amount of mass.

The most basic way to implement physics for this point is to "forward" its velocity in some way.

## Step 2: Timesteps

We can't assume our game will run at the same speed all the time. It might run at 15 frames per second for some users, but at 60 for others. It's best to account for frame rates of all ranges, which can be done using a timestep.

This way, if a frame were to take longer to elapse for one person than for another, the game would still run at the same speed. For a physics engine, however, this is incredibly unstable.

Imagine if your game freezes for a second or two. The engine would over-compensate for that, and move the `PointMass` past several walls and objects that it would otherwise have detected a collision with. Thus, not only would collision detection be affected, but also the method of constraint solving we'll be using.

How can we have the stability of the first equation, `x = x + velX`, with the consistency of the second equation, `x = x + velX * timeElapsed`? What if, maybe, we could combine the two?

That's exactly what we'll do. Imagine our `timeElapsed` was `30`. We could do the exact same thing as the latter equation, but with a higher accuracy and resolution, by calling `x = x + (velX * 5)` six times.

The algorithm here uses a fixed timestep larger than one. It finds the elapsed time, breaks it up into fixed sized "chunks", and pushes the remaining amount of time over to the next frame. We run the simulation little by little for every chunk our elapsed time is broken up into.

I picked 16 for the timestep size, to simulate the physics as if it were running at approximately 60 frames per second. Conversion from `elapsedTime` to frames per second can be done with some math: `1 second / elapsedTimeInSeconds`.

`1s / (16ms/1000s) = 62.5fps`, so a 16ms timestep is equivalent to 62.5 frames per second.

## Step 3: Constraints

Constraints are restrictions and rules added to the simulation, guiding where PointMasses can and cannot go.

They can be simple as this boundary constraint, for preventing PointMasses moving off the left edge of the screen:

Adding the constraint for the right edge of the screen is done similarly:

Doing this for the y axis is a matter of changing every x to a y.

Having the right kind of constraints can result in very beautiful and captivating interactions. Constraints can also become extremely complex. Try imagining simulating a vibrating basket of grains with none of the grains intersecting, or a 100-joint robotic arm, or even something simple as a stack of boxes. The typical process involves finding points of collisions, finding the exact time of collision, and then finding the right force or impulse to apply to each body to prevent that collision.

Comprehending the amount of complexity a set of constraints can have can be difficult, and then solving those constraints, in real time is even more difficult. What we'll be doing is simplifying constraint solving significantly.

## Step 4: Verlet Integration

A mathematician and programmer named Thomas Jakobsen explored some ways of simulating the physics of characters for games. He proposed that accuracy is not nearly as important as believability and performance. The heart of his whole algorithm was a method used since the 60s to model molecular dynamics, called Verlet Integration. You might be familiar with the game Hitman: Codename 47. It was one of the first games to use ragdoll physics, and uses the algorithms Jakobsen developed.

Verlet Integration is the method we'll use to forward the position of our PointMass. What we did prior, `x = x + velX`, is a method called Euler Integration (which I also used in Coding Destructible Pixel Terrain).

The major difference between Euler and Verlet Integration is how velocity is implemented. Using Euler, a velocity is stored with the object and is added on to the object's position every frame. Using Verlet, however, applies inertia by using the previous and current position. Take the difference in the two positions, and add it to the latest position to apply inertia.

We added acceleration in there for gravity. Other than that, `accX` and `accY` won't be necessary for solving for collisions. Using Verlet Integration, we no longer need to do any sort of impulse or force solving for collisions. Changing the position alone will be enough to have a stable, realistic, and fast simulation. What Jakobsen developed is a linear substitute for something that's otherwise nonlinear.

The benefits of Verlet Integration can be best shown through example. In a fabric engine, we'll not only have PointMasses, but also links in between them. Our "links" will be a distance constraint between two PointMasses. Ideally, we want two PointMasses with this constraint to always be at a certain distance apart.

Whenever we solve this constraint, Verlet Integration should keep these pointmasses in motion. For example, if one end were to be moved quickly down, the other end should follow it like a whip through inertia.

We'll only need one link for each pair of PointMasses attached to each other. All the data you'll need in the link is the PointMasses and the resting distances. Optionally you can have stiffness, for more of a Spring constraint. In our demo we also have a "tear sensitivity," which is the distance at which the link will get removed.

I'll only explain `restingDistance` here, but the tear distance and stiffness are both implemented in the demo and the source code.

You can use linear algebra to solve for the constraint. Find the distances between the two, determine how far along the `restingDistance` they are, then translate them based on that and their differences.

In the demo, we account for mass and stiffness as well. There are some problems in solving this constraint. When there are more than two or three PointMasses linked to each other, solving some of these constraints may violate other constraints previously solved.

Thomas Jakobsen encountered this problem as well. At first, one might create a system of equations, and solve for all of the constraints at once. This would increase in complexity rapidly though, and would be difficult to add more than even just a few links into the system.

Jakobsen developed a method that might seem silly and naive at first. He created a method called "relaxation," where instead of solving for the constraint once, we solve for it several times. Each time we reiterate and solve for the links, the set of links become closer and closer to all being solved.

## Step 6: Bring It Together

To recap, here is how our engine works in pseudocode. For a more specific example, check out the demo's source code.

## Step 7: Add a Fabric

Now we can construct the fabric itself. Creating the links should be fairly simple: link to the left when the PointMass isn't the first one on its row, and link up when it isn't the first in its column.

The demo uses a one-dimensional list to store PointMasses, and finds points to link to using `x + y * width`.

You might notice in the code that we also have "pin PM." If we don't want our curtain to fall, we can lock the top row of PointMasses to their starting positions. To program a pin constraint, add some variables to keep track of the pin location, and then move the PointMass to that position after every constraint solve.

## Step 8: Add Some Ragdolls

Ragdolls were Jakobsen's original intentions behind his use of Verlet Integration. First we'll start with the heads. We'll create a Circle constraint which will only interact with the boundary.

Next we can create the body. I added each body part to somewhat accurately match the mass and length proportions of a regular human body. Check out `Body.pde` in the source files for full details. Doing this will lead us to another issue: the body will easily contort into awkward shapes, and look very unrealistic.

There are a number of ways to fix this. In the demo, we use invisible and very unstiff links from the feet to the shoulder and the pelvis to the head in order to naturally push the body into a less awkward resting position.

You can also create fake-angle constraints by using links. Lets say we have three PointMasses, with two linked to one in the middle. You can find a length between the ends in order to satisfy any chosen angle. To find that length, you can use the Law of Cosines.

Modify the link so that this constraint will only apply when the distance is less than the resting distance, or, if it's more than. This will keep the angle at the center point from ever being too close or too far, depending on what you need.

## Step 9: More Dimensions!

One of the great things with having a completely linear physics engine is the fact that it can be any dimension you'd like. Everything done to x was also done to a y value, and thereforce can be exended to three or even four dimensions (I'm not sure how you'd render that, though!)

For example, here's a link constraint for the simulation in 3D:

## Conclusion

Thanks for reading! Much of the simulation is heavily based off of Thomas Jakobsen's Advanced Character Physics article from GDC 2001. I did my best to strip most of the complicated stuff, and simplify to the point that most programmers will understand. If you need help, or have any comments, feel free to post below.