More Springs

Please see Golan’s Notes on Springs. This page is full of great examples using Particle and Spring objects.

This page has some additional notes on designing software, using springs as an example.

The question is: How do we represent springs?

There is no one answer.

How would you implement springs?

Let’s look at several different ways. All are “correct,” but you may find some methods more attractive than others. We’ll use the triangle example.

Springs as Code

Let’s start by simply “hard coding” the spring forces using code. Every time we run draw(), we’ll have draw() run some code that explicitly calculates spring forces and applies them to particles.

In this approach, the springs are implemented in code, and we can say even represented in code — there’s no variable or object that can say “I am the spring!” No, the springs are in the code.

First, let’s remind ourselves how this code behaves:

Implementation Details

Let me call your attention to code in the middle of draw():

    // Springs and their forces are represented here by the code
    // itself.
    // Advantage: You can read exactly what computation is done.
    // Disadvantage: Irregular forces and connections could require
    //    a lot of special cases in the code.
    // Spring connections are from every p[i] to p[(i+1) % n]
    for (var i = 0; i < myParticles.length; i++) {
        var p = myParticles[i];
        var q = myParticles[(i + 1) % myParticles.length];
        springCalculateDraw(p, q);

As you can see, the loop in line 8 finds pairs of adjacent particles in myParticles and applies spring force by calling springCalculateDraw(p, q), which also draws the spring. Notice the use of the modulo operator (%) so that the "next" particle wraps around to index 0 when we get to the last particle.

Here is springCalculateDraw(p, q). It calculates and applies forces between particles p and q. Note that all springs have the same length and spring constant. If this were not the case, we'd have to calculate or look these up these in the code somehow and pass them in as additional parameters:

function springCalculateDraw(p, q) {
    var dx = p.px - q.px;
    var dy = -;
    var dh = sqrt(dx * dx + dy * dy);
    if (dh > 1) {
        var distention = dh - restLength;
        var restorativeForce = springConstant * distention; // F = -kx
        var fx = (dx / dh) * restorativeForce;
        var fy = (dy / dh) * restorativeForce;
        p.addForce(-fx, -fy);
        q.addForce(fx, fy);
    // now draw the spring
    line(p.px,, q.px,;

Springs as Properties

Another way to represent springs is particle-centric. What if the particles “know” what springs they are attached to? Then, when we update the particles, each particle can calculate spring forces for each spring it is attached to.

After a little thought, it seems simpler to attach each spring to one particle rather than both particles. The particle that “owns” the spring will be responsible for calculating the force at both ends of the spring. Thus we can use the same springCalculateDraw() function shown above.

If we were to associate each spring to both particles that it attaches to, we’d have a representation that seems like a more faithful model of the overall system, but then we’d have to calculate each spring force twice — once for each particle — or we’d have to somehow prevent the second particle from recomputing the spring forces applied by the first particle.

Implementation Details

Here’s an implementation where springs are represented as properties of particles. Each particle has a property called connections, which stores an array of other particles. In the triangle example, each connections array will have just one other particle representing a spring between this particle and the other particle.

Here’s the modification to make the connections. (We could have used the “modulo” trick and a loop, but in this case just made the connections separately.)

function createSpringMeshConnectingParticles() {
    // Stitch the particles together by springs.
    var p0 = myParticles[0];
    var p1 = myParticles[1];
    var p2 = myParticles[2];

And here’s the implementation of the connect() method:

var Particle = function Particle() {
    this.connections = [];
    this.connect = function(p) {

Finally, the render() method of Particle is modified to calculate spring forces. Note the iteration over all the connections in line 4:

    this.render = function() {
        ellipse(this.px,, 9, 9);
        for (var i = 0; i < this.connections.length; i++) {
            var p = this.connections[i];
            var dx = this.px - p.px;
            var dy = -;
            var dh = sqrt(dx * dx + dy * dy);
            if (dh > 1) {
                var distention = dh - restLength;
                var restorativeForce = springConstant * distention; // F = -kx
                var fx = (dx / dh) * restorativeForce;
                var fy = (dy / dh) * restorativeForce;
                this.addForce(-fx, -fy);
                p.addForce(fx, fy);
            line(this.px,, p.px,;

The complete code for springs as properties is here.

Springs as Objects

Finally, we come to the approach shown in Golan’s Springs page, where springs are represented explicitly as objects. You can go to that page to see the code. The main things to look for are:

  1. There is a new object type: the Spring
  2. There must be a list to keep track of springs as well as particles
  3. There must be a loop to apply each spring’s forces to connected particles at each frame
  4. There must be code to create each spring object and “attach” it to particles


There you have it. Three ways to represent springs: as code, as properties, as objects.

Code is creative and definitely has an esthetic component. Which method is simplest? Which seems right? Which is most beautiful? Which is most understandable? Which is most flexible?

These are all important attributes of code. Designing good code that balances all these concerns is as much an art as it is science or engineering.