You know, in some ways making software must be like making a work of art, because I find that my emotions are somehow tied to the thing I'm working on, especially this project. When it's working well and improving I get happy, but there's a palpable down feeling when it's not working. Sometimes stepping through code with a debugger feels like punishment for having been stupid. I guess it shouldn't but...

By the way, I had some fun with my green laser and long exposure picture. That's me!

Once the tensegrity was viewable it became abundantly clear that I had made some big mistakes in the physics calculations. Now that they're working beautifully I'm feeling really good. Getting from there to here was a bit of a struggle, and building software is much more humbling than most people realize because you get exactly the behavior that you program and nobody writes perfect code first time. You always have to look back and pity the previous version of yourself who wrote that stupid code. Funny.

The first problem was the hopeful idea I had to remove "slack" from the whole tensegrity thing and have cables pull proportionally to their length. That turns out to be dead wrong, and no good tensegrities can be built that way. I watched them slip out of shape and fall flat a number of times, and then it was clear that cables need to be more intense about their lengths. They have to pull hard when they're just a bit too long. So the first refactor was to move the "span" number back into the superclass Interval of Bar and Cable so that both entities have spans again.

The second problem was that the Joint actually has to have more than just two arrows: position and movement. To do quadratic drag there must be a velocity arrow, and to handle the bar physics there has to be another arrow to separate all the calculations related to cables, which I have called cableForce. This allows the physics to let all the cable forces on a joint accumulate, do the calculations with them, and only later apply the resulting force to the velocity of the joints. The cancelling of the opposing forces in a Bar that I described a little while ago must happen separately like this for it to work. Then the velocity can just be diminished according to its quadrance (the square of it's length or distance).

So the Joint class now holds three arrows. It's position, velocity, and an extra arrow to hold the cable forces that accumulate, cancel out, are applied to velocity, and then zapped back to zero during every tick of the clock (every call to step() in the Physics class).

Which brings me to Physics, which I had to largely rewrite because it had to work very differently. This is what I talk about mostly in the podcast. I'm amazed at how wrong it was, and happy that it has now become clearer and simpler at the same time as becoming "correct". The coolest thing of all is that the floor is now not solid but somewhat fluffy instead, just as listener Matt Dick suggested. It's even pluggable using the ResurfacingStrategy interface.

The updated version is available using Java Web Start from http://www.darwinathome.org/tensegrity-20071006/

Technorati Tags: