Contact generation is the process whereby, after a collision is detected, the points of contact are defined, which are necessary to simulate collision response(responses themselves are anything from a simple separation of the bodies to an in-depth physics sim).
In the most naive form of contact generation, you move the bodies, let them intersect each other, and only afterwards do something to remove them by finding the points of intersection after they've already interpenetrated. Even with simple situations, this is the source of numerous glitches, and makes physics sims unstable, since the two interpenetrating bodies will both see that they're "inside" each other, create forces to get out the situation, and then collide with other bodies, repeating the process, gaining energy, and making the sim explode, or at least jitter endlessly. (Collisions between many close-by bodies also present other contact quality problems - bodies might "miss" each other and only contact some of the other shapes.)
The speculative contact system described is one approach towards resolving these kinds of instability problems: Basically, it uses velocity information to "look ahead" at where the body will move, and then it adjusts the velocity vector to fit so that the two bodies touch exactly. This can be repeated for all potential collisions, until the minimum movement for each body is found, at which point contacts may be generated.
I happened to discover exactly this technique independently, trying to make a simple game collision system as robust as possible even at high velocities. Velocity appears to be a critical piece of information for robustness, as all the heuristics I tried to separate bodies already interpenetrating led to major glitches when the heuristic guessed wrong. I also tried a very similar method of "rolling back time" by moving the body backwards along its existing velocity with a step-by-step approximation, until the collision no longer happened; this turned out to not be as good as modifying the future velocity vector to touch exactly, as it was cruder, left points of contact inexact, and thrashed the original velocity values, leading to things stopping dead and "sticking" as soon as they collided anything at all.
I don't have much experience either, but here's my best attempt:
Speculative Contacts is a fairly new technique for collision detection - solving the problem of are any objects trying to occupy the same space at the same time? without taking too long over it.
This blog is talking about one advantage of SC, which is stability. Physics engines are hard to write, and stability is one problem that you come across when trying.
Suppose you have a ball falling towards a plane. You move the ball, then discover that it's intersecting with the plane, so you move the ball back a little until it's not.
But now suppose you have two balls. When you move the first ball back, now it's intersecting with the second ball. If you try to solve that, you might run into problems with a third ball, or with the plane again. And so on.
Stability is the problem of solving all these constraints in a way that looks good. Roughly, that means the balls should be touching but not visibly intersecting, and they shouldn't be jittering (moving a few pixels per frame, but staying in roughly the same position). This is a hard problem.
Usually you run the constraint solver (moving things so they're not colliding, but potentially generating new collisions) multiple times to try to get stability, and there are other techniques available. What the blog post is saying is that none of that is necessary with SC: it gives you stable simulations with only one pass of the constraint solver and without running any other fancy algorithmhs.
The description seems to ignore elastic collision - contact always occurs on a frame boundary which is noticeable wrong when higher velocities occur. Wouldn't the described solution result in 'sticking'?
No, because the rebound velocity doesn't depend on how far two bodies intersect.
To answer the wider question - when a contact is detected, you can immediately calculate the new velocity of the two bodies. Then you move things around to be nonintersecting. Then next frame, everything has the correct velocity.
(In fact, this will be done in two passes. Collision detection will generate a list of contacts, containing properties like the initial velocities of the two bodies. Then the collision resolution phase will change the velocities.)
Could someone explain this in simple terms to someone with only a tiny bit of physics engine experience?