Physics for Game Programmers: Understanding Constraints

January 5, 2019

Physics for Game Programmers: Understanding Constraints

Constraints in Game Physics

Youtube – GDC - Physics for Game Programmers: Understanding Constraints

By: Erin Catto

EDIT: Updated to correct "resolute" constraint to "revolute" (Jan 5, 2019)

Erin goes over the importance of physics constraints in physics game programming and how to implement them to add diversity and creativity when designing physics for games.

Erin explains that physics constraints are to physics programmers as shaders are to graphics programming. You can use the already existing recipes that will get the job done, but designing your own will allow you more flexibility and creativity.

Shaders – lighting, shadows; Physics constraints – revolute, prismatic

Position constraint: in example, it is a particle that is restricted to a surface. Appears the equation should be 0 if particle is on surface, than < 0 or > 0 depending on what side of the surface it is on if it moves away from surface.

Contact constraint: the contact points on the contacting bodies do not move relative to each other along the contact normal

Global solvers vs Local solvers: Global solvers would solve everything somewhat simultaneously by having everything in a single large matrix equation setup. Local solvers are used to do computations linearly and solve one thing at a time.

Physics solver will need to iterate multiple times to solve impulses, but cannot run enough times to get everything completely accurate which leads to some overlap.

Iterations allow for convergence of the system’s solution and the actual determined solution. The iterations and time for this convergence to occur vary based on the complexity of the physical system. In the examples, circle stacks with assigned mass values were used. It turns out heavier masses on top of smaller masses leads to much slower convergence, and it gets slower as the mass ratio increases. This occurs because the solver needs to bring the top circle to rest, but each iteration it does on the contact occurring between the two circles only removes a small amount of the large circle’s velocity because it does it relative to the size of the lower circle.

Warm Starting – since a lot of things in games aren’t moving all the time, you can “save” impulses to try initially later so that it will have a saved solution if it hasn’t moved and if it starts moving, it may be closer to the next solution already This does not do well with quick load changes.

Inequality constraints – only want impulses to be able to push, not pull (lamba > 0); For accumulated impulses, you actually don’t want each incremental impulse to be restricted by > 0, you just want to apply that to entire accumulated impulse. Sometimes you need negative incremental impulses to solve cases of overshooting. This is when impulse applied at a step is actually too great and you need to bring it back down.

Global solvers are great but too expensive.

Don’t use acceleration constraints because it leads to cases where you need an infinite force to truly stop an object instantaneously, which is theoretically what should occur in rigid body collision.

Link to Erin Catto's box2d.org

References from the talk:

• David Baraff: Coping with Friction for Non-penetrating Rigid Body Simulation
• Metthias Muller: Position Based Dynamics