I have implemented your algorithm and here's what I found by playing around with the numbers. Note, that this is after commenting out the solvePenetration() method, thereby, transferring all contact resolution to a velocity based system.
1.) The jittering stopped when standing on two inverse mass=0.0f tiles. This was the exact result I was looking for, and by playing with three parameters, the iterations, the "d" and the "k" I was able to come up with a global solution that was stable (of course it's only a 2d game where block stacking is not necessary, therefore, I did not do a full body physics test). But all things considered, it works very well.
2.) A new problem now cropped up. When an AABB with finite mass is "walking" along infinate mass tiles which are placed adjacent to each other (horizontaly), the algo you supplied allows for a little sinking into the existing tile, which means that if I am "walking" right, the bottom right corner of finite mass AABB snags the top left corner of the tile being walked on providing for a rough jerking motion which should be smooth acceleration.
If you have any ideas how to solve this, please let me know. I tried a few hacks, for example turning off gravity when the entity is standing on a mass=0.0f ground, but non of these have proved to adequate for realistic non snagging movement.
What change in behaviour do you experience when changing the number of iterations?
what happens when you have a lot of interacting bodies either stacked or pulling each other via constraints?
When I have an AABB with finite mass, resting (more specifically after falling, ie due to gravity) onto 2 or more infinetly massed AABBs, the finite mass AABB starts to jitter.
Now, if I have an AABB with finite mass resting on one infinitelly massed AABB, there's no jitter and the object is settled.
If I have many objects resting on top of each other, especially ones with bigger masses resting on smaller masses I get jitters, but that's usually if there's more than 3 or 4. For my game purposes this is not a concern as I am not attempting to do a physical simulation.
I strongly suspect that the issue is what you told me about earlier,
Could it simply be that while the corrective impulse from interacting with brick #1 is exactly enough to counter the finite mass objects perp velocity vector due to movement and gravity, the the impulse caused by interaction with brick #2 does not take this into account and applies the same impulse, resulting in overshoot?
However, I am not exactly sure how to solve this problem. I tried two different SAT algos, and one works better than the other, but the issue persists.
I mention John Carmack and Q3 exclusively because if I remember correctly, he was the only one given credit for programming the game, although I could be wrong after all these years. I don't think I have ever seen another major title with only one programmer's name finding so much success.
Could someone educate me on this point as well.
Was not his work on lighting wich made him so popular, as before Q3, game worlds were rather drab and lacked the brilliance of detail and dynamic lighting often associate with Q3?