[33a]

Collisions are violations of the pairwise non-intersection constraint between bodies. Collision forces are Lagrange multipliers of these constraints. Collision normals are the (normalized) partial derivatives of the constraint function wrt one of the body's configurations.

[mort96]

That sounds like the kind of thing which works if you're doing physics at 1kHz+ with an integration algorithm with good numeric stability which honours conservation of energy, but in games, we're often running physics at down to 30Hz using some ad-hoc Euler-Chromer, which requires very different approaches

[33a]

It's still the same principle even in games. If you are trying to explain where forces come from and how resolution works, you need to ground it in something. Otherwise you are just adding extra assumptions onto assumptions.

[mort96]

In proper physics simulations, everything's about forces, most things are springs, and you never teleport stuff. In games, modelling the ground as a spring really doesn't work and teleporting entities when they collide with parts of the world often makes a lot of sense. It's just not the same.

EDIT: If I'm incorrect, please explain how. I've written some game physics systems and seen some proper physics sim systems and these comments reflect my understanding of the situation, and if I've said something wrong, please correct me instead of just downvoting.

[33a]

The principle of least constraint is the basis for rigid body mechanics based contact forces. This has been known since the days of Gauss and Hamilton, and is fundamentally how restitution and collision forces are derived in Lagrangian mechanics. There's a long literature on this going back more than a hundred years.

It's true that some commercial solvers like Ansys use spring/penalty methods, but this is due to the spring forces being easier to couple to other solvers. It's harder in the Ansys force/velocity formulation to combine things like elasticity and fluids to their rigid body solver. To deal with the instability of systems of many stiff springs they have to take many small timesteps to avoid convergence issues.

More recently techniques like XPBD have been gaining popularity, particularly in film, which use purely positional constraints and variational methods to combine many different types of physics simulations. There's a really great and approachable series of videos by Matthias Muller on youtube which goes through how to implement all this in JS https://matthias-research.github.io/pages/

Finally it's funny you should mention games, since many older games used spring methods for physics. It was only when constraint based solvers became popular after Havok/Half-Life 2 did we start to see games with real rigid body dynamics and stable stacking of boxes. Older physics games like Trespasser ( https://en.wikipedia.org/wiki/Trespasser_(video_game) ) had many bugs due to the use of hacky spring physics. For a good explanation of how games do it today look at Erin Catto's work on Box2D https://box2d.org/publications/

[bollu]

Neat! do you have a resource that explains this perspective further?

[33a]

Posted a reply here https://news.ycombinator.com/item?id=40466855

This is a specific reference on how constraints model contact between rigid bodies https://box2d.org/files/ErinCatto_UnderstandingConstraints_G...

Most games since Half Life 2 use constraint forces like this to solve collisions. Springs/penalty forces are still used sometimes in commercial physics solvers since they're easier to couple with other simulations, but they require many small timesteps to ensure convergence.

[buzzcut_]

I second this. I would love to learn more.