Velocity Verlet Integration Change

[pcottle]

Hi Christian:

As we discussed, I have modified the Physics simulation to use velocity verlet integration. There is a considerable stability improvement in low-friction simulations.

To see the stability difference:

• Open up the halfviz demo for this fork by running the python SimpleHTTPServer.
• Select "abominable snowman" from the examples list
• Set Friction to 0%
• Increase spring tension and monitor performance of the nodes. For me, around 3300 is when I begin to get "flickering" of the nodes. I suspect jittering occurs here because the timesteps are too large for such high forces.

To compare to the stable branch:

• Navigate to http://arborjs.org/halfviz
• Select "abominable snowman"
• Set Friction to 0%
• Increase spring tension. Jittering for me begins around 1800, and once going into a jittering state, there is a considerable hysteresis (you must go far below 1800 to obtain stable motion).

The only issue with this change is that the nodes reach stability quite quickly in most simulations, and the code to turn off the simulation activates too soon (because it detects a low amount of energy I believe). It can be somewhat visually jarring. I'm not sure where this code activates or if there is a default parameter to change (I looked for it in physics.js but had no luck), but changing this deactivation constant to a lower parameter might obtain the best results.

Let me know what you think. This is my first pull request!

Thanks, Peter

[samizdatco]

peter, thanks so much for the patch. your changes were admirably minimal and though it took a little wrangling i was able to make the integration algorithm switchable (note the new argument to the ParticleSystem constructor, though verlet is the new default).

the settling-too-fast problem was due to the system energy calculation occurring before the velocities were updated. that seems to be solved at this point (though let me know if it needs additional tweaking).

one thing i've noticed in the demos that allow drag-and-drop is what seems like a slower mass-decay process. in your comments you mention that caching acceleration rather than force might improve dynamic-mass behavior. have you experimented with this at all? it seems better `in theory' and i'm wondering if it also makes a real-world difference.

thanks again, cds

[pcottle]

Christian:

No problem! I'm honestly quite honored that my patch made it in; that's awesome that you made the behavior switchable (and figured out the settling bug). It makes me believe in this whole open source thing :P

In terms of the mass decay issue, while looking into it I kinda discovered a larger issue. Originally I assumed that you were keeping the mass of all particles to be 1, which is why it seemed that you used acceleration and force interchangeably -- for example, in the "old" code when you calculate velocity, you just add F * timestep (instead of accel * timestep).

After seeing this, I assumed that the mass of each particle was 1 and the change in mass over time was zero. Then I began to write my code, using accel and force interchangeably (trying to follow your convention).

The reason this worked is because all the dynamics of the system are based off of repulsion forces, so if one constant is missing from all the calculations (mass in this case), the system behaves the same.

This goes out the window if the mass changes, which is why you were seeing such weird behavior on dragging and dropping!

I now realize that you are setting high mass values when doing drag and drop, meaning that the code needs to be changed a bit. I've gone ahead and made the necessary changes, both to cache the old acceleration values and to include mass in all the verlet physics calculations. It works even better now!

I've also updated the atlas demo to include mass changes when dragging (I used 25 instead of the commented out 10000). Now there is a very nice (and frankly quite beautiful effect) when dragging and dropping -- all the other nodes are repulsed a little bit when clicking on a node. They then settle nicely when the node is released as well.

It's a separate topic so I'll make a new pull request. Thanks again for getting back to me!

[pcottle]

Also Christian I just want to note that we will be using arbor.js for a cool "social network" visualization at Facebook this summer! It's just a hackathon project for now but I think it could turn into a permanent art installation; I'll keep you updated but great work on arbor!