Physics frequency

My demos have the config set to 60Hz.

The jittering (probably) comes from how you preocess simultaneous collisions/contacts. If you precess them iteratively and independantly, then if you have, for example, a box resting on a plane with 4 contacts at the corners, then the total impulse that you'll end up with (after iterating) will exceed the impulse required to counteract gravity AND it will be different at each corner of the box.

If you go the other way and calculate the impulses required at each point, but then average in some way before applying, then the total impulse may not actually be enough (resulting in either your box sinking down, or using more passes than should be needed).

I ended up doing something in between.

I think anything you do should be able to run at 50/60Hz. Some people run stuff at 30Hz, I think...

Thanks for the reply, MrRowl. Actually it was your cool demos which inspired me to try and implement better physics for my game.

Currently what I do is, I find the collision points and then average them. Then I apply the impulse at this averaged point. The problem is, as you said, it's not strong enough to prevent the cuboid from sinking into the ground. So what I do is, I just validate the positions while checking for collisions. But the jittering remains.

In your demos, I noticed that the objects come to rest and don't keep "jittering" around. If you don't mind, could you give me a hint about how this was accomplished?

Thanks,
Francis Xavier

They get deactivated when they pretty much stop moving. You can toggle this feature by pressing 'f' (or tweak the config file) to see how they behave without it.

It's quite tricky to get really robust and efficient object activation/deactivation - even commercial libraries like novodex and meqon can mess up sometimes. You can look at the jiggle source code to see how I did it there - it's similar to jiglib.

Thanks! I'll check out the source again.

It had occurred to me that I could deactivate the objects when they pretty much stopped moving, but I also found it quite tricky to get it right.

Another thing, if I may ask you, is how do you actually deactivate the objects when they pretty much stop moving? What I do is, I see if their velocities are below a certain threshold and then make them zero. Is this the proper way to go about things?

Checking the object's velocity (and angular velocity) is the "normal" way of doing this, I think.

However, I do it by checking to see if the objects position moves less than a certain amount in a given time. This way little oscillations in the velocity aren't a problem - so long as the oscillations don't cause any real visible movement the object can still be deactivated. If you just use the velocity then I found that working out a value for the velocity threshold could be tricky.

The hard bit is work out when to wake objects up (I do use a velocity threshold for this). For example, removing a block from the bottom of a stack of objects should wake up the whole stack immediately. However, removing it from the top shouldn't wake any objects up. If you wake objects up too easily then piles of objects have trouble going to sleep as they all keep waking each other up (my demo suffers from this a bit).

Major fast replies, dudes! :D

Anonymous Poster, you're right; I totally overlooked that! And I was just lucky (unlucky) that the effects of this didn't occur during testing.

MrRowl, your idea of using the position of the object instead of its velocity seems to be cooler than what I'm doing. I was having a rough time setting the correct velocity thresholds.

But, as you said, a new problem comes into the picture - that of knowing when to wake objects up. Hmm...

I was thinking, there's something funny going on with the equations. I implemented rigid body physics after going through Baraff's papers. But there's one thing which puzzles me.

When the coefficient of restitution is set to 0, the body correctly loses complete linear motion on collision and appears to stick to the colliding plane. But the same doesn't happen with rotational motion. For e.g. when a cuboid (falling due to gravity) hits the ground at an angle so that a single vertex collides first, that vertex sticks to the ground. Then the cuboid rotates so that another vertex hits the ground. But instead of the second vertex getting stuck to the ground on impact, and the rotation getting stopped completely, the cuboid's rotation only slows down, then starts again in the opposite direction with some loss of energy.

Is this behaviour a bug in my code, or does this occur normally?
Anyone has any ideas about this?