Game network physics collision

Perhaps the best thing that you can do is not so show the actual collision real time, but give the illusion that things are happening in real time.

Since the client is behind the server (lag), and the server needs to show the result of the collision, perhaps what you can do, client side, is to show a flash or explosion or some other graphic to distract the user and buy enough time on the server side to calculate the result of the collision.. When you are finished with the prediction, you ship it back to the client side for presentation.

I don't know of a perfect solution, and I have a feeling that one does not exist. Even if you could accurately predict the future position of the vehicle, you would be unable to predict the way the user will operate the controls. So the problem comes down to minimizing the negative effects of client/server lag. With that in mind, I would approach this from the position of the principle of least astonishment (paraphrased from Wikipedia):

In user interface design, the principle of least astonishment (or surprise) states that, when two elements of an interface conflict, or are ambiguous, the behaviour should be that which will least surprise the human user at the time the conflict arises.

In your example, each user sees two vehicles. Their own, and that of another player. The user expects their own vehicle to behave exactly the way they control it, so we are unable to play with that aspect of the simulation. However, the user can not know exactly how the other user is controlling their vehicle, and I would use this ambiguity to hide the lag from the user.

Here is the basic idea:

1. The server has to make the decision about an impending collision. The collision detection algorithm doesn't have to be 100% perfect, it just has to be close enough to avoid obvious inconsistencies.
2. Once the server has determined that two vehicles will collide, it sends each of the two users a message indicating that a collision is imminent.
3. On client A, the position of vehicle B is adjusted (realistically) to guarantee that the collision occurs.
4. On client B, the position of vehicle A is adjusted (realistically) to guarantee that the collision occurs.
5. During the aftermath of the collision, the position of each vehicle can be adjusted, as necessary, so that the end result is in keeping with the rest of the game. This part is exactly what MedicineMan proposed in his answer.

In this way, each user is still in complete control of their own vehicle. When the collision occurs, it will not be unexpected. Each user will see the other vehicle move towards them, and they will still have the feeling of a real-time simulation. The nice thing is that this method reacts well in low-lag conditions. If both clients have low-latency connections to the server, the amount of adjustment will be small. The end result will, of course, get worse as the lag increases, but that is unavoidable. If someone is playing a fast-paced action game over a connection with several seconds worth of lag, they simply aren't going to get the full exeperience.

Sorry to answer with "What not to try", but I've never heard of a solution that doesn't involve predicting the outcome on client side. Consider a simplified example:

Client A is stationary, and watching client B's vehicle approach a cliff. Client B's vehicle is capable of reducing speed to 0 instantly, and does so at the last possible moment before going over the cliff.

If Client A is attempting to show Client B's state in real time, Client A has no choice but to predict that Client B fell off the cliff. You see this a lot in MMORPGs designed such that a player's character is capable of stopping immediately when running full-speed. Otherwise, Client A could just show Client B's state as the state updates come in, but this isn't viable, as Client A needs to be able to interact with Client B in real time in your scenario (I assume).

Could you try simplifying the collision models so that extrapolation is possible for real time prediction? Maybe make your "joints and bodies all over" have processor-less-intensive physical models, like a few cubes or spheres. I'm not too familiar with how to improve the efficiency of collision detection, but I assume it's done by detecting collisions of models that are less complex than the visual models.

Regarding "What not to try". You are assuming that you need to predict perfectly, but you are never going to find a perfect solution in a game with complex physics. An approximation is probably the best you can do (for example, most commercial physics engines can cast a shape into the physics scene and return the first point of collision).

For example, I implemented some critical parts of the network physics for Mercenaries 2 under the guidance of Glenn (the blog poster you mentioned). It was impossible to push all of the necessary physics state across the wire for even a single rigid body. Havok physics gradually generates contact points each frame, so the current "contact manifold" is a necessary part of the physics state to keep the simulation deterministic. It's also way too much data. Instead, we sent over the desired transform and velocities and used forces and torques to gently push bodies into place. Errors are inevitable, so you need a good error correction scheme.