🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Simultaneous collisions

Started by
12 comments, last by arnero 4 years, 5 months ago

Completely rigid worlds suffer from static indeterminacy. Consider a table with four legs of equal length. If you try to solve for the forces on each leg, there's no unique solution. For three legs, there is. But for four, very tiny differences in leg length mean huge changes in the forces, because only three will touch the ground.

This has real-world implications This is why tripods are stable but four-legged chairs can wobble. It is why older truss bridges are all triangles. For triangles, the stresses can be computed statically by hand.

Because of this, rigid body collision solvers are doomed to get some cases wrong. This is usually not a big problem in games because most of what's going on is blowing stuff up. But it will show up as a problem if you try to simulate a vehicle with no suspension.

Ref: https://en.wikipedia.org/wiki/Statically_indeterminate

Advertisement

Interesting page here: https://www.myphysicslab.com/engine2D/collision-methods-en.html

Ah thank you, ‘statically indeterminate’ was missing from my vocabulary in trying to understand this area better. That now directly brings up a whole heap of interesting stuff regarding all this I can dig through :-) It also leads to FEM stuff.

This jumping off point is quite useful too:

https://en.wikipedia.org/wiki/Solution_procedure_for_Indeterminate_Structures

The link MrRowl gave, I was recently reading too, and is good food for thought.

>FEM
Uh that wikipedia page, I do not understand it. The difference to finite differences seem to be the more precise and automated generation of the equations for the boundary conditions. I mean, when you use a very fine finite differences mesh … ah okay I see. Matrix inversion gets costly with more differences. Still, chosing elements looks like black magic to me.

After sleeping over the statically indeterminate vocable, I now understand billard. The balls are not stacked and therefore there is always a small gap between them. In my simulation which I wrote as kid I used fixed time steps (60 fps) to calculate the deceleartion. Within each step the balls move linearly with a constant velocity. I then use merge sort to keep all collsion points sorted in time using the 32 bit of a 386SX. No one could blame me when I retard or advance one or another collision by 1 µs (the time step of the 32bits) to always get only-2 body collisions.

This topic is closed to new replies.

Advertisement