So I've been working from the ubiquitous "Nonconvex Rigid Bodies with Stacking" paper (but 2d instead of 3d), and have most of it implemented but not perfected. I still got jitters! In the simplest of cases, a block on an immovable ground, the following happens: Each frame, it resolves collisions/contacts/shocks whatever at each point, first the bottom the left then the bottom right, but since I'm applying the impulse of each before moving on to the next, the result is that it moves a teeny-tiny bit to the right, since i process the right vertex last - the impulse it creates there does not cancel out the impulse generated at the left one, and there is a slight movement. If the right impulse completely cancelled out the left impulse, it would be still, but it doesnt! I'm not sure why not. Precision limitations? Problems in my algorithm? Anybody know? So theres a couple things I'm thinking of experimenting with there, I can condense those two impulses into a single one at the midpoint of the two, so theres only one impulse needed which will keep it upright. I've tried this and it does work, but then it opens doors to new problems. Behold, the ever popular jenga-tower, tumbling over here: Its a little more confusing figuring out what is going on here. I believe its just a case of the above jitter multiplied by the height of the tower, adding up to enough to topple the damn thing. So if I took the approach of condensing collisions to only one per-edge, that might help here.. but would it be physically accurate? then you would have weird cases like three small-blocks producing only a single impulse on the block stacked on top of it (does that make sense?) Or maybe the jitter is just something I have to live with, and do my best to cancel it and stop it, "sleeping" algorithms that detect when an object is jittering and cease its motion. That seems likely to generate lots of false positives, though, especially in cases like this: In this case you almost WANT some jitter, cause now the damn thing wont fall over! Its the shock algorithm, it seems: each block individually can stand on its lower one, and when you shock it and set the base blocks to infinite mass as you go up, they dont have any reason to topple over. I guess cranking up the iterations will help here, but theyre already pretty high.... I'm hoping a few people here can lend some advice here, as these are I'm sure pretty common problems, and I'm using a pretty common algorithm so someone must have some ideas of how to fix them, or at least what exactly the problem is! -John Krajewski

I haven't programmed a physical simulation yet, but shouldn't you be using two separate buffers for objects? One for their current state and another for their state in the next frame (=after applying impulses to the objects from the current frame); you would then just swap the two buffers after each world update..

your last pic show exactly the problem with shock propigation

in practice it isn't likely enough to be a problem

Jittering in most physics simulations doesn't ALWAYS come out of the blue...
I agree with Devilogic, however, because of the fact that your objects seem to move in a specific direction. You are probably using data in the simulation that you calculated in the very same frame. That's wrong! I'll try to examplify... Imagine that you're simulating two planets in orbit. At any given frame, you don't just calculate the new position of planet A given the position of planet B, and then use the new planet A data to derive those of planet B. That's wrong. You should only use snapshots of the objects exactly as you left them in the previous frame.

However, some jittering is often seen in such applications. Even though a box should be resting on a flat surface, the physics/collision algorithms keep on igniting collision responses between them -over and over- and this produces this annyoing jittering you're getting.

The best way to deal with this, is define 'kinetic energy' traps [kinetic energy is: (mass*velocity^2)/2 ] for your objects and flag them -somehow- as 'temporarily inactive' when their kinetic energy drops below a certain minimum. Only use this if you have unyielding objects in your scene (like the floor in your app). This prevents the algorithm from flagging the very same collision in consecutive frame, when an object should rather rest, but use it with extreme caution (for the obvious reason)