Rigid body physics bouncing boxes problem

Started by
6 comments, last by Randy Gaul 8 years, 9 months ago

Hi,

I'm trying to put together a small physics engine by following some tutorials that I've found on the net. It is using the impulse-based method.
The result is good for spheres but boxes keep bouncing infinitely. I've no idea why this might be happening. Looks like when computing the angular velocity for boxes some energy is being added to the system. I've not yet added the frictional impulse but I'm manually adding some damping to the linear and angular velocities when integrating. Here is a screen recording showing the problem;
I'm generating one-shot multiple contacts by using Sutherland-Hodgman clipping along with SAT.
Does anyone know why this might be happening? Is this a known problem in the impulse-based method?
Thanks
Advertisement

Wrong sign?

Division throug zero (nearly zero) ?

Try to add an some criteria to abort your calculation if the change ins position is small enough.

I guess this is not a problem of the impulse based method, should be more a numerical problem, which often occurs on solving equations on computers

Is this a known problem in the impulse-based method?

No, these are your implementation bugs! smile.png Either the contact geometry or you impulses computations are wrong. Or both of course!

You need to test two boxes first and visualize the contact point creation. Rendering the proxy bounds and origin in your situation is obfuscating and not helpful. First make sure you get the clipping, normal and penetration depth correct. You don't need to simulate anything. E.g. a good test is to stack two boxes on top of each other and rotate the top one 45 degrees. You should find eight points in this case. Then flip the bodies to make sure it works both ways with the correct normal.

Then you need to test dynamic computation. It helps to only solve for non-penetration constraints first. Disable penetration recovery (Baumgarte stabilization) and also friction. Then add one them in one after the other to isolate the problem.

Physics simulation is relatively easy since you can draw everything and only check one detail at a time. If you run into problems like this isolate individual pieces of your simulator and verify their correctness.

I have seen what you are showing myself many times. Most of the time it were simple mistakes like wrong signs and wrong indices. You seem close, so don't get discouraged! Just don't *blindly guess* what the mistake might be, but take a structured approach for debugging as I described above and improve your debug rendering as needed. Good debug rendering will payback big time in the future! So it is a good investment of your time.

Your gravity looks wrong as well. Also check your inertia tensors if the angular impulses appear wrong.

HTH,

-Dirk

Yeah looks mostly like collision detection bugs to me. Debug rendering specific bits of code is a great way to find and isolate bugs. It could also be helpful to find some reference code to check your math/derivations against, etc.

It looks to me like it could either be a problem with your inertia tensors, or possibly also with the penetration depth computation/Baumgarte stabilization. If your collision detection returns too big a penetration depth, it can cause those 'teleportation' problems where the object jumps up in the air after collision, since it tries to correct for a very large (but incorrect) penetration.

Hi guys,

After long hours of debugging and sleepless nights, I finally found the issue. I checked the contact data, penetration depths, normals and everything else was correct. The problem was in the calculation of inverse inertia tensor world.

Previously I was calculating inverse inertia tensor world like this;

* Create a rotation matrix from the rotation quaternion of the rigid body.

* Multiply this matrix with the inertia tensor and then invert.

After checking some other people's code I changed it like this;

* Get the inverse of the transform matrix. (M1)

* Copy its transpose into some other temp matrix. (M2)

* Multiply the result with the inertia tensor. (M2(inertiaTensor))

* Inverse inertia tensor world = (M1(M2(inertiaTensor))))^-1

Thanks for all the replies, I knew there was a problem in the inertia tensor calculation.

Uza

I went ahead and simplified the calculations to R(inverseInertia)R-1 to get the inverse of world inertia tensor. Since RT and R-1 equivalent, now I'm using R(inverseInertia)RT (Right to left) which makes sense.

Congrats! That kind of debugging is a really difficult to learn skill.

This topic is closed to new replies.

Advertisement