Let's be honest! I am falling in love with the p5.js framework. It makes my algorithms and simulations so beautifully presentable! And that too with so minimum amount of boilerplate.

After building a Mandelbrot set simulator, I thought, why to stop here, let's build something related to Physics, which I loved very much during my +2 days. Then the idea of creating the Gravitation simulator came into my mind.

The Physics Involved

Gravitation comes under (classically) Central forces.

The magnitude of gravitational force between 2 point masses $m_1$ and $m_2$ separated by a displacement of magnitude $r$ is given by:

$$ F = G \cdot \frac{m_1 \cdot m_2}{r ^ 2} $$

where $G$ is the universal gravitational constant, with value $$G = 6.674 \cdot 10 ^ {-11} m ^ {3} kg ^ {-1} s ^ {-2}$$.

Combining this with Newton's famous 2nd law, the magnitude of acceleration $a$ of $m_1$ is given by:

$$ a = \frac{F}{m_1} = G \cdot \frac{m_2}{r ^ 2} $$

Now, actually in space, every celestial body moves towards every other due to the Gravitation. That'd indeed be an incredible multi-body dynamics problem to solve. But our scope is pretty simple. We'll just consider $m_1$ to be movable. Other bodies would be stationary.

Gravitation is always attractive (Shhhh! GTR fans). What that means is, if, by some magic, $m_2$ was pinned down at a fixed point, $m_1$ will always move TOWARDS $m_2$ with the acceleration given above.

Note that the acceleration is independent of $m_1$, so whether we take a rock or a planet, the path traced out by them would be the same.

Approximations and rescalings

The Gravitation is very weak as a force. Using $G$ directly in the simulation is not practical. So for the simulation, I use a different scaling constant, which I pick by hand and constrain the acceleration values within some handpicked bounds, to do away with the problem of division by zero, when $r=0$.

Another cheating that I do in the simulation, is that I keep all object's mass as 1. For the simulator, $1$ body of mass $m$, is the same as, $m$ bodies of mass $1$ located at the same point.

I also work in 2D plane and decompose the accelerations in X and Y axes using the slope of the line joining 2 bodies.

So, if $m_1$ (moving mass) is located at $(x_1,y_1)$ and $m_2$ (fixed mass) is located at $(x_2,y_2)$ , the components used are (with a scaling factor of 100):

$$ a_x = \frac{100 \cdot (x_2 - x_1)}{r ^ {\frac{3}{2}}} $$

$$ a_y = \frac{100 \cdot (y_2 - y_1)}{r ^ {\frac{3}{2}}} $$

I also clip $a_x$ and $a_y$ between some bounds.

The total acceleration of the mass $m_1$ is the component-wise sum of accelerations over all the fixed masses. That is to say, at a given time:

$$ \vec{a}_{total} = \Sigma a_x \hat{i} + \Sigma a_y \hat{j} $$

I'll drop the sum sign from here on.

The last approximation has to do with how I calculate the velocity and position in the next timestep.

In reality, velocity would be a nice and smooth time integral of the acceleration and the displacement would be a time integral of the velocity.

Here I approximate integral by sum.

I take a small timestep $\Delta t$ (in simulation, it has value 1). Then calculate:

$$ \vec{v}_{next} = \vec{v}_0 + \vec{a} \cdot \Delta t $$

$$ \vec{r}_{next} = \vec{r}_0 + \vec{v}_{next} \cdot \Delta t $$

Of course, the calculations are done component-wise.

The code, finally

With all the above considerations in mind, let's jump right into the code.

The index.html loads the p5.js library as usual. Notice that I have created fields for initial position and velocity as well as buttons for starting and resetting the simulation.

The main juice of the code is sketch.js:

• particles array contains the location of the fixed unit masses;
• position and velocity correspond to the moving mass.
• started and stuck are simulation states.
• lines contains the set of points along the path traced by the moving mass.

In the draw function, I check if the mouse is pressed WITHIN THE CANVAS, I add that location to the particles array.

However if started is set to true, I no longer add bodies, rather I proceed on calculating the next position at every frame.

Finally, I draw the fixed particles as green circles and the moving particle as a red body which leaves a red trace.

This logic works fine, until the red body from very far off comes very near a green body. In this process it gains tremendous velocity and shoots out of the screen. To prevent that from happening, the stuck variable is set to true whenever such stuff happens. And once set to true, the particle's position is not updated, it remains stuck.

This sticking behaviour is controlled by the metric in Line 40. The value to which it is set in the code hardly has any effect. Change the threshold to 1 or 10 to see the sticking effect.