2D verlet physics tutorial

[CommanderKeith]

I know some of you already know all about verlet physics (KevG, Riven), but for the rest of us, there’s an easy to understand 2D verlet tutorial on gamedev.net that was recently published:

http://www.gamedev.net/reference/programming/features/verletPhys/default.asp

Unfortunately the sample code is in C++ but I think I get the idea. Looks pretty neat.

[Riven]

It’s a real shame that acceleration is a vector in that code. Then you can just as well make velocity a vector.

Acceleration can be calculated, without time, by recording not 2 but 3 positions of each particle.

Acceleration = (P_now-P_old) - (P_old-P_older)

If you have a body (set of particles with springs connecting them) acceleration will be a side-effect of movement (and collision). With 1 particle (not a body) it won’t really work when colliding.

Example:

P_now = (18, 101)
P_old = (15, 101)
P_older = (13, 101)

v_old…now = (18, 101) - (15, 101) = (3, 0)
v_older…old = (15, 101) - (13, 101) = (2, 0)

a_older…now = (3, 0) - (2, 0) = (1, 0)

[CommanderKeith]

Thanks for pointing that out. Would one method work better with a non-constant frame rate?

What about the limitation of only using convex polygons? Would it be worth making a different collision detection algorithm to do concave polygons, or would it be ok to just split the concave polygon into a few smaller convex polygons and connect them up somehow?

Cheers,
Keith

[Riven]

The nice thing of Verlet is that you don’t have to worry about … anything.

Just make a body by connecting Particles with Springs.

If a particle is intersecting a triangle (just build your shapes out of triangles…) then push that single particle out of the triangle, and that’s it. Due to the springs and other particles (that all have momentum) things will bounce off, getting angular velocity… you name it. The conversion from 2D to 3D physics is trivial: add a Z coordinate and you’re done.

Think of it like atoms in real life. They don’t know anything about cos/sin/sqrt, they don’t even have collisions, only (electromagnetic) forces. They just act as independent particles with little springs (forces), and on a very high level, they behave as if they are performing very complex mathematical calculations, projecting themselves onto planes and whatnot, to figure out their next position, while in reality, they don’t know squat.

[DzzD]

[quote]Thanks for pointing that out. Would one method work better with a non-constant frame rate?
[/quote]
you should use a fixed time granularity, let say 10ms

if you have to simulate the physics for 30ms (because your last frame was 30ms ago) you just perform 3 physics loops : this is important for the correctness and stability of the physics simulation model.

this is important because using too bigs times steps will results in completly wrong result :
the fastest your object go (compared to its size) the smallest the timestep must be and more generally you should never move on atome more than half the lenght of the n constraints (springs length) it is connected to.

EDIT : this is why it is pretty hard to push such object with a huge force (still in comparaison of its mass & size), because such force will result in a hight cceleration and so a too big move

[DzzD]

//Push both vertices apart by half of the difference respectively 
//so the distance between them equals the original length
E.V1->Position += V1V2*Diff*0.5f; 
E.V2->Position -= V1V2*Diff*0.5f;

this represent a Spring with an infinite k constant producing an infinite force for any displacement => such spring does not exist and this wont work in 3D or if an Atome have more than two connections in 2D.

because of the interaction of springs on each other I guess it is also better even in 2D to use a smaller value and iterate n times.

[Riven]

Noticed that too…

This is my code:

   public final float tick()
   {
      float ax = a.now.x;
      float ay = a.now.y;
      float az = a.now.z;

      float bx = b.now.x;
      float by = b.now.y;
      float bz = b.now.z;

      float dx = ax - bx;
      float dy = ay - by;
      float dz = az - bz;
      float dist = (float) Math.sqrt(dx * dx + dy * dy + dz * dz);

      if (how == MIN_LENGTH)
      {
         if (dist > len)
            return 0.0f;
      }
      else if (how == MAX_LENGTH)
      {
         if (dist < len)
            return 0.0f;
      }

      float tension = (this.len - dist) / dist;
      float force = tension * this.stf;

      float aw = a.invWeight;
      float bw = b.invWeight;

      float f1 = force * aw / (aw + bw);
      float f2 = force * bw / (aw + bw);

      a.now.x = ax + dx * f1;
      a.now.y = ay + dy * f1;
      a.now.z = az + dz * f1;

      b.now.x = bx - dx * f2;
      b.now.y = by - dy * f2;
      b.now.z = bz - dz * f2;

      return tension;
   }

[DzzD]

I also found better that before moving anything Atome/Particle using springs constraints it is a good idea to integrate/accumulate them for each particle into another vector and once all constraints force (spring force) has ben computed move each particles with its corresponding accumulation vector, this will make the order you proceed them independant of the resulting move and will result in a better simulation (EDIT : it also let the possibility to check the length of each accumulation vector before applying them)

[Riven]

@DzzD

I also found better that before moving anything Atome/Particle using springs constraints it is a good idea to integrate/accumulate them for each particle into another vector and once all constraints force (spring force) has ben computed move each particles with its corresponding accumulation vector, this will make the order you proceed them independant of the resulting move and will result in a better simulation (EDIT : it also let the possibility to check the length of each accumulation vector before applying them)

Very true. I think the same can be accomplished by moving ‘old xyz’ in the opposite direction, so that the next step will push the particle along.

[CommanderKeith]

Great advice DzzD and Riven, I’ll have a go at making a demo using your ideas.

I’m interested in this because I want physics in a 2d look down bird’s eye view style of game. Since there’s no stacking of bodies in such a game and most of the time there’s no contact between bodies (unlike in a platformer) verlet physics seems like the best candidate since it’s simple and easy to implement/understand and it’s weakness of stability won’t be a big issue.

[pjt33]

Shame it skips over loads of important stuff like particles having different mass, elastic collisions, external forces (e.g. gravity), etc. There’s enough info there to make a basic quadrature testbed but people who didn’t feel the article was overly dumbed down probably don’t know enough physics to turn it into something useful for a game.

[CommanderKeith]

Another great tutorial (with references) : http://www.metanetsoftware.com/technique/tutorialA.html

It comes with source too, but it’s in an swf and an fla file. I tried opening it in FlashDevelop (http://www.flashdevelop.org) but it came out garbled… Anyone know how to open this stuff and see the source?

[Ranger]

@CommanderKeith

I know some of you already know all about verlet physics (KevG, Riven), but for the rest of us, there’s an easy to understand 2D verlet tutorial on gamedev.net that was recently published:

http://www.gamedev.net/reference/programming/features/verletPhys/default.asp

Unfortunately the sample code is in C++ but I think I get the idea. Looks pretty neat.

That tutorial is great! Thanks for pointing it out.

Does anyone know of a simple Verlet code example with collision detection / reaction written in Java? (So far I couldn’t find any, so I’m thinking about converting the supplied C++ sample code to Java)

EDIT: I ended up porting the C++ code to Java. Here is the result as an Applet: http://verlet.googlecode.com/