This may occur because collisions modify a ball’s position but not its velocity.
Balls are also attracted to each other more the further away they are from each other, which is wacky.
Here’s the most relevant code:
Dunno why that makes it converge, but those are some differences from normal elastic collision.
Correction: balls aren’t attracted to each other, they’re attracted to the centre and they’re more attracted the further away they are, which gives us orbit type things (but I think not the ones gravity would give).
This is mesmerizing (and weirdly nerve-wracking) to watch.
@Corbin Is there a TLDR for what the bug was and what’s happening? I found the GH repo but don’t want to wade through the C++.
My grasp of orbital mechanics and differential equations is quite poor; we need a cosmologist or particle physicist.
Having said that, and having read @cmcaine’s sibling comment, I can guess at least a few things. The curves are orbit-shaped because of Hooke’s Law being used to update the velocity as a function of position; each ball is on one end of an invisible spring, with the other end at the origin; this is like a very light object orbiting around a very heavy object. I think that each pair of colliding balls is rotated around their combined center of gravity, but since collision doesn’t change velocity, this merely shifts each ball into a new orbit which is less likely to have a repeat of the same collision.
I might have a better understanding after coding it up myself, but it appears that we are iteratively optimizing a collection of orbits around a nucleus towards a minimum number of collisions. I would wonder how long it takes to settle and whether it always settles. I would not be surprised to learn that the initial positions and velocities can encode a computation, nor to learn that it’s Turing-complete to decide whether a given initial configuration settles.
So, it’s not a bug, it’s a feature :P