Processing: Further Physics Experimentation – Gravity

Continuing on from my previous work based on concepts from physics using the The Nature of Code as a starting point, (blog posts are found here Mass, Friction and Fluid Resistance and here Vectors and Forces: Part 2) I decided to look into ways of making interact with each other instead of just a force that is applied from outside as in my previous work.

To start I created a sketch very similar to my earlier one where objects were attracted to the position of the mouse. However the physics for this are not very realistic, as the location vector of the object we want the others to be attracted to (in this case the mouse) is just simply subtracted from the location vector, then normalised, halved and and added back onto the location vector. This method means that the objects tend to bunch up after a certain amount of time and very quickly follow the mouse. To combat this I looked into forces that apply to similar situations in real life. An obvious area to look into in this case would be the force of gravity.

To begin modifying my sketch I added a new class called Attractor which would contain a better way of attracting the objects. To get the correct mathematics for the process of gravity it is necessary to look at the formula for gravity.

gravity
Where G is the universal gravitational constant, however for the purpose of the sketch we can ignore this and set it to one

I implemented this in the code with this method. To start with the method needs to take the Mover argument to be able to use data from that object such as the mover’s distance. This can then be accessed by lines such as
m.location which gives us the mover objects location. The actual computation of gravity comes from the line float strength = (G * mass * m.mass) / (distance * distance); .

PVector attract(Mover m){
    // Get the force's direction
  PVector force = PVector.sub(location,m.location);
//Get the magnitude to get the distance
  float distance = force.mag();
//constrain it so it doesn't become too strong or weak when the object is too close or far
  distance = constrain(distance,5,25);
  force.normalize();
  //the equation for gravity
  float strength = (G * mass * m.mass) / (distance * distance);
  force.mult(strength);

  // Return the force to apply it 
  return force;
  }

In order to use the resulting force in our code we need a way to apply it to the mover objects. So I made an applyForce method in the Mover object which is the same as the method used in the fluid resistance sketch. This method takes a PVector and adds it to the acceleration but also divides it by the mass beforehand, so heavier objects are less affected by the force than lighter ones.

 void applyForce(PVector force){
   PVector f = PVector.div(force,mass);
   acceleration.add(f);
 }

To implement this in the code is quite simple, as we cycle through the array of mover objects in the main sketch we calculate the gravitational force by calling the attract method using a.attract(movers[i]); and the resulting PVector is applied using applyForce.

for (int i = 0; i < movers.length; i++){
//attractor (a) calculates gravitational force for each mover object
  PVector force = a.attract(movers[i]);
//force is applied
  movers[i].applyForce(force);

Below is the finished sketch.

envision
Sketch of an idea I had

From testing these sketches and following on from my concepts explored in Interactive Design Project: Initial Designs, especially my idea of orbs of light that follow the audience around the room. From this, I had an idea of using the same principles and code above for my installation piece. People could be used as the Attractor objects and the movers could float around them.

In order to test this out I decided to add more Attractor objects to the skecth, as well as make them move to see how this affected the motion of the mover objects. To make the Attractor objects move I used the Brownian motion simulation I used in Processing: Object Orientated Programming so they will move quite slowly, but randomly across the screen.

Overall I think the effect is pretty good however there are some issues I will need to try and fix, such as the mover objects bunching up too much around a singular Attractor object and not spreading out enough. However I could fix this quite simply with adding a decay feature to the attraction force so that it decreases over time or over space.

As discussed by Palmer (2005) on his discussion on video games, realistic physics are essential to a programs immersion. Players use real life physics as a reference in their expectations of how something will move or react. This is even true in fantastical elements in a game. For example, even though hoverboards aren’t real, we expect them to move in the opposite direction of thrust and outside forces, such as wind, to have an effect on its trajectory. In order to make the project more accessible to the audience, I will continue working on my understanding of forces and physics in a programming context. I will also begin working with cameras to find out how the added complexity of camera based interaction will affect the simulation and the level of audience participation.

Shiffman, D., 2012. The Nature of Code [online] Mountain View: Creative Commons

Palmer, G., 2005. Physics for Game Programmers New York: Springer Verlag