Why is it so interesting to create a sytem like this from scratch with so few basic assumptions (read: so little code)?

All the evolution code in Darwin at Home has so far been based on Elastic Interval Geometry which works with structures made of springs. The definition of a spring involves both pushing and pulling depending on whether the spring is shorter or longer than it wants to be.. it's default span. There was enough of a focus on tetrahedra and octahedra and the growth process was careful enough that there were rarely intervals that cross each other. They were programmed to grow in ways that didn't result in curling up inside themselves, but it could still happen and if it happened crossing went undetected.

Any tensegrity growth algorithm looks like it will involve lots of crossings of bars and cables in its intermediate phases (when a new element appears) and since crossings are not permitted in real life there will have to be a way of having the offending bars and cables somehow evaporate. It's easy to do that, but it will be a challenge to have it work in ways that can evolve, hopefully discovering some kind of strategy through natural selection.

Another major departure from previous Darwin at Home work will be that these tensegrity bodies will not be evolved in their "adult form". Until now I've been having mutated peers compete and passing from generation to generation was a question of body copying followed by a tiny mutation. The evolution of tensegrities will be very different because bodies will have to start from scratch every generation and grow before they compete. Think of it as a kind of larva phase which has to proceed correctly in order for the adult tensegrity to become a successful contender. Hey and this process could even happen in a state of "altered physics" where, for example, the viscosity could be increased, preventing wild jittering as the cables "harden".

But this is still "future music" as we would say in Dutch. For now some difficult groundwork has to be done to deal with this new thing we have to be able to measure: Proximity. In this podcast episode 24, I try to explain in the clearest possible way what the math is behind the proximity of intervals (bars, cables), and how the software approach involves ghost objects called Cross which we don't see, but which persist as long as there is a danger of two intervals crossing. Also interesting is the Proximity class and how it does the Cross calculations, and why this visitor construction is the best way to implement proximity calculation.

Technorati Tags: