To get to know more about this project, please check the Week 1 article where I introduce this project.

During Week 8, I started by adding friction to the game engine. Friction is a force that resists the motion of a body, which means it’s opposite to where the body is moving towards. Granted, friction in real life is more complicated than what we represent it as, however, the approximations we do during the calculations, make the latter seem natural enough.

So the way I represented friction is as an impulse along the negative tangent vector of the collision. And when it comes to deciding the tangent, we take the tangent closer to the new relative velocity, which makes sense, since we want the friction to be along the negative of that vector, to resist the motion of the body.

A couple of things to keep in mind when working on friction. First, we need to follow Columb’s Law, which basically clamps the friction impulse to the impulse along the normal. Second, we need to decide on how to calculate the friction factor from both bodies friction factors. I chose to go with a simple average. And last but not least, we need to think about how to represent dynamic friction. I just chose to multiply the static friction factor by a number less than 1 (0.7f to be exact) to get the dynamic friction factor.

Here’s the code that I added to the collision resolution method to account for the friction impulse resolution:

And here is the result of those changes:

After adding friction, I tackled one of my biggest challenges during this project so far: Adding rotational movement, which means adding Torque and Angular velocity.

So I started working on that, however, once I did, I noticed I had a problem in my simulation: the mass of the object affected its free fall speed, which does not make sense. I didn’t notice that before, but when I changed a couple of densities to match real life materials like steel, I discovered that I was resolving gravity incorrectly.

Thus, to fix that, I changed UpdateForces and UpdateVelocities from:

To:

It was a mistake on my part that I didn’t notice because the simulation seemed fine at the time.

After fixing that bug, I did some research on how to add torque. I found this paper that talks about impulse resolution for translating and rotating bodies, which was really informative. The first thing I noticed is that I needed to retrieve the collision contact point. So I added that to the Manifold structure that I added previously, and I populated that in the collision detection phase. I had a problem with Polygon vs Polygon though because the way I implemented SAT, I don’t deduct the collision points from my computations, so that’s the first order for next week update. I noticed also that I needed to implement the perp-dot product, which is the equivalent of the cross product in 3D. That is why I called it Cross product in my implementation:

After that, I updated my impulse resolution computations to account for the angular velocity and to apply torque to the contact point:

Now the results for Circle vs Circle were solid, however, Polygon vs Circle was wacky. Not to mentions polygon vs Polygon since I don’t have correct contact points as of now, which led me to believe that I might have some issues in my polygon inertia computation, so I need to recheck that too next week.

Here is the result for Circle vs Circle:

You can always check the project on my GitHub.