Darwin at Home

On this noisy walk in the bush I start by giving a listen to the remarkable spring wildlife in the bush near our place on the east end of Rotterdam, and then I explain a unit test.

Now, what could be more exciting than a unit test?! I know. Actually, there's a very good reason why this unit test is absolutely crucial to building the infrastructure for the game, so there's no way around it. It's too important to skip over.

TestBeingMarshalling.java

Technorati Tags: darwin java evolution

Good news for Java developers!

I worked all friday on the DaH code, rearranging everything so that I can start the final construction of the online game. All the parts are now available under one tidy subversion directory:

svn co https://fluidiom.svn.sourceforge.net/svnroot/fluidiom/dah/

If you can figure out how to install JOGL on your machine, you should be able to watch the program evolve in the coming weeks.

I had to separate off the core DaH classes into their own maven jar artifact when I realized that this exact same code must work on both the client and the server.

This is getting more fun! Just a few more sessions and I'll probably be able to put a demo online.

Technorati Tags: java evolution darwin

In this podcast episode I continue to describe the developments on the way to the new version of the online darwinathome program. Marshalling is all about transforming fabrics (bodies) to a binary format and back into object graphs again. The Fablob (Fabric BLOB) class does the work and it can store fabrics in either lossy or non-lossy form, depending on what the situation demands. It will be used for database storage, http communications and also for fabric cloning (during evolution).

Also I've put together a datamodel using Hibernate and Postgres, and it maintains the genaeology of the fabrics; the parent-child relationships so we can store lots of fabrics in the database and we can brows through the ancestors of any fabric to see how it developed.

Technorati Tags: evolution marshalling persistence genaeology

In this podcast episode I describe two of the improvements that I have been able to make in the past couple of months during evenings and weekends. Time has been tight lately since I've been working intensely on my contract with the team at the European Library to finalize the site which is finally going live right now. The project is called Europeana and it functions as a search engine for a mountain of metadata about european cultural heritage collections from all over the continent.

Also, I've managed to implement a really nice simplification of how the Fabric class works. Fabrics used to be just joints and intervals with these two things mutually pointing at each other, so it was possible to ask a joint for the intervals that meet there. This involved a lot of bookkeeping when the fabric was being edited, and things started getting complicated when I introduced "faces" (trianglular), "tetras" (four joints), and even "vertebra" (those tensegrity modules). Should a joint also be aware of the faces, tetras, and vertebrae to which it belongs? Too much work.

The way the Fabric class works now is that it's centered around the joints, and they hold no references to any other entities. Instead collections of faces, tetras, and vertebrae can be extracted from a fabric using what looks a bit like an SQL query. Give me the tetras connected to joint X. Since it's all in memory these queries are lightning fast, and it makes the code quite a bit simpler.

I've built quite a bit of other stuff already too, but I'll talk about those things in subsequent podcasts soon, now that I have a bit more time available. Stay tuned!

Technorati Tags: evolution darwin geometry physics

In this podcast I get on to the next step in the blind watchmaker development, assuming the first three steps described in the last podcast are meeting no resistance.

Sensory observations are to be communicated back to the genome interpreter in the form of instructions that return nuances.

We could choose among different subroutines, but in this episode I try to make a case for introducing symmetry.

Blind Watchmaker

1. binary genome
2. nuances
3. cost
4. forking
   • Instruction return values
   • void or null means continue normally
   • return nuance means make a choice
   • fork could choose different genome paths
   • ... but would it be legitimate to introduce symmetry??

Technorati Tags: evolution darwin blind-watchmaker

In this podcast episode I get into the first details of how the Blind Watchmaker works, since the design seems to be solidifying into something that looks tight and actually has proven to do something, building D@H bodies. The next step, as I said at the last Greythumb gathering, is to get the blind-watchmaker code to also manage behavior.

The plan now is to go step by step from the very basics of the blind watchmaker development, and see if people can contribute ideas and maybe code as we go. At least people can stop me from doing stupid things, if they're listening.

Blind Watchmaker

1. Generic Binary Genome & Instruction Sets
   • Bit strings
   • Invented but remembered
   • Short bit string --> method call
2. Nuance parameters (with bit precision)
   • Spectrum between two ends
   • They come from the genome
3. Cost
   • Default is bit-length
   • Instructions represent expenditure
   • Observations are acts too

Technorati Tags: evolution greythumb darwin blind-watchmaker

Done with building the tensegrity by hand, I've decided that for now it's too difficult for me to evolve anything interesting with tensegrity shapes. There's a lot of design to be done with them, And I'll be continuing that most definitely, but for evolution I'm going to search elsewhere

In this episode of the podcast I talk about this and the direction that things are going now. I've returned to the code that makes up all the previous versions of Darwin at Home and I'm working intensely to distill the best things from them all into a toolbox that can be used to build a number of applications.

Next tuesday the 23rd of September at the Dutch Royal Academy of Visual Arts in Den Haag we will be holding the second Greythumb Netherlands gathering. If you're interested, please join the group online.

I wanted pretty badly to present something interesting at that gathering, and finally my work of the last while is starting to pay off because I've been able to build a program where "bits build bodies". The blind watchmaker project with its genetic system, is now connected to the new fluidiom-core classes I've been distilling, and producing lots of interesting geometrical phenotypes.

Technorati Tags: evolution darwin java opengl

In this episode of the podcast I once again go for a walk in the bush, and this time talk about the change in direction that the Nuance Engine has taken, as well as about the very first Greythumb Netherlands get-together.

Here's a picture of WORM, where Greythumb NL was held in June:

..and here is the duck (a WORM-sponsored work of art, for you cultural barbarians!)

I've decided to change the name of the project to Blind Watchmaker because I no longer like the association "engine", and it's one of the most thought-provoking archetype memes that Dawkins introduced with his book of that name.

I'll save going into the actual Blind Watchmaker code until I've got it stable enough. It's going to be a neat system, which lets you submit instruction sets and takes it from there.

ecodesic

This is the first crack at creating a mini-universe in which the Blind Watchmaker system will be demonstrated. The little balls you see represent creatures that move around on the surface of the planet. Listen to the podcast to hear about how I plan to try and turn this into a Blind Watchmaker programming competition.

Technorati Tags: evolution

Let's try something new! I found out about a trick that allows me to put this JOGL application into the form of a Java Applet which makes running it more straightforward since it just appears on a web page.

Please give the new version of the Tensegrity World Applet a try and let me now if it works for you without a hitch. You are asked to approve the JOGL extension which comes from Sun Microsystems, but that shouldn't be a problem.

This applet shows growing tensegrities, and they are growing on the basis of "Cell" objects which are each attached to individual tensegrity segments. So far the code of the cell is very simple. It just waits a short while, sprouts a new segment, and then vulcanizes itself. The new segment is given a new cell, which does the same thing only it vulcanizes slightly earlier than the previous one. Eventually this will all be orchestrated by a genome.

In this episode of the podcaset I talk about what this applet is doing, and what it should eventually develop into. Lots of work has been going into getting the tensegrity code prepared to work with the Nuance Engine, although this version doesn't yet show the connection. That will take a little more work.

For those of you in the Netherlands, don't forget the upcoming Greythumb NL Gathering at WORM! I hope to see you there.

Technorati Tags: evolution artificial life tensegrity darwin binary

In this episode of the podcast I continue where I left off last time, but this time it's about making the first connection between the nuance engine and something else. Needless to say, the first thing that deserves trying is to somehow get the nuance engine to build tensegrities! I discuss the approach that seems to make the most sense.

Also, it appears to be possible to set up an applet that uses OpenGL via JOGL without having to use Java Webstart. The nice thing about applets is that they just sit there on a web page, rather than you having to launch them. (..and ever since browsers started storing JNLP files instead of just using them to launch and keeping them hidden, Webstart has become a slightly dirty process, leaving droppings behind). Next version should be an applet with a text field for you to type binary numbers 0101010010101010, which are used as genotypes to generate tensegrity phenotypes.

Technorati Tags: evolution artificial life nuance darwin binary

In part 1 I talked about the layer that takes in a stream of bits and spits out a series of nuances. To complete the nuance engine we will need more code on both ends of this. On the bitstream end there will have to be a system managing the streams, performing mutations and crossover, and managing the population. On the other end there has to be a system in place which takes the stream of nuances and translates it into some kind of execution of a program. That's what this episode of the podcast talks about.

We start with a NuanceStream where successive nuances can be consumed, and we want instructions executed. For this I have employed two great features of Java: Annotations and Generics. The result is really nicely pluggable/configurable system where a class corresponds to an instruction set.

The main annotation is @Instruction which marks a method to be a "nuanced instruction", meaning that it takes zero or more nuances and it returns a nuance. What work it actually does is of no concern to the Nuance Engine. It may be making an observation using senses and adjusting memory, or it may be observing memory and actuating a muscle. The whole thing may be trying to solve a math problem, or build a tensegrity, we don't know and we don't have to know.

It may be the case that a particular nuanced instruction has fairly meaningless behavior if there isn't enough smoothness in the nuances that it receives as parameters. If your job is to pick a screen location, a two-bit nuance may not be "precise" enough. This is why the @Instruction annotation requires an integer argument, which indicates the minimum precision of the nuances the instruction requires. This is a silly example of an instruction method:

    @Instruction(3)
    public Nuance printSomething(Nuance nuance) {
        System.out.println("At least three bits precise: "+nuance.value(0,10000));
        return howFinished;
    }

There are two possible bit strings which cannot reasonably be translated into nuances: "", the empty string, and "0", the string of precision 1. Beyond that there are only two possible values for a precision 2 string, "00" (false) and "10" (true), and for precision 3 there is "000" (false), "010" (maybe), and "100" (true). All of these low-precision nuances would be not terribly "nuanced", so there is an option to use them for something else: controlling the nuance engine. For this, the second annotation @MetaInstruction was introduced. The instruction set can have any one of these seven bit string values "", "0", "00", "10", "000", "010", "100". Higher precision bit strings are always treated as nuances, and these are as well (precision 2 and 3) when there is no meta-instruction assigned to them.

    @MetaInstruction("")
    public Nuance mainControl(NuanceEngineControl control) {
        System.out.println("I can control the engine");
        return howFinished;
    }

    @MetaInstruction("0")
    public Nuance lessFrequentControl(NuanceEngineControl control) {
        System.out.println("I can control as well");
        return howFinished;
    }

The NuanceEngine iteself is a generic class, which means that you have a nuance engine for every instruction set. As you can see, the execute instruction takes a nuance stream and an instruction set, which indicates that the bit stream is used to execute instructions.

public interface NuanceEngine<InstructionSet> {
    void setTerminationThreshold(Nuance threshold);
    void execute(NuanceStream nuanceStream, InstructionSet instructionSet)
            throws NuanceException;
}

Which works like this:

        NuanceEngine<SimpleInstructionSet> engine = new Engine<SimpleInstructionSet>();
        engine.setTerminationThreshold(new FloatNuance(1f));
        SimpleInstructionSet instructionSet = new SimpleInstructionSet();
        engine.execute(nuanceInputStream,instructionSet);

The type-safety introduced by the generics approach makes for nice refactoring! Also, the tidiness of the annotations makes gluing things together really easy. Your job as evolver is to extend the phenotype by building an instruction set and annotating its nuanced instruction methods and a few meta-instructions methods. The rest is handed over to the blind watchmaker so that bit strings can climb mount improbable and you can maybe find an ancestor's tale about whatever domain you are evolving.

InstructionSetContainer.java - the real workhorse here

I'm almost surprised by how little code is involved with the Nuance Engine so far! It's clearly distinguished in layers, and the only code that breaks a sweat is the InstructionSetContainer, because it has to interpret the annotations and execute the instruction methods according to nuances from a bit stream. I think I'm speaking another language right about now. Hope you're enjoying it. Don't forget that there's also a podcast where I chat about this stuff as the code develops.

Technorati Tags: evolution artificial life nuance darwin binary

It's time to look into generalizing the evolution process so that the same mechanism can be used in any of a great number of different domains. I've devised an interesting approach based on something I talked about during a previous podcast episode. In the end I want to be able to grow algorithms, and I want those algorithms to be defined by strings of bits like 0100101001010101001010110110110101010.

The strategy is not to chop the bit string into equal length chunks like bytes, 16-bit words, or 32 or 64 bit words. Instead, it's more interesting to get different lengths of bits coming out of the "genetic code", and I should eventually be able to demonstrate why.

I would like to introduce the "Nuance" concept. It's as simple as could be because a Nuance is just an immutable truth value, which can be false or true or anything in between. The code for the nuance specifies only an interface which allows you to extract the value by specifying the domain:

public interface Nuance {
    int precision();
    int value(int low, int high);
    float value(float low, float high);
    long value(long low, long high);
    double value(double low, double high);
}

By calling one of the value functions you can use the nuance for any numerical purpose that makes sense. As we continue, you will understand why this is the basis of the evolution system.

Just one nuance is not enough to make for some interesting genes, so there is something called a nuance stream which provides for reading nuances one after the other out of some source. You use the nuance, and then move to the next one.

public interface NuanceStream extends Nuance {
    boolean next();
}

So now comes the fun part. Remember how the Fibonacci binary code worked? It was all about using the two-bit delimiter 11 to signify the end of one word and the beginning of the next. Call it a "space". Random strings of bits will have 11 appear fairly frequently, of course, and the words left over between these spaces never contain the 11 so not every bit sequence comes out as a word.

That's why I used the name Fibonacci. There is 1 entry of zero length, 1 entry of one-length, 2 of length 2, 3 of length 3, 5 of length 4, 8 of length 5 and so on all the way down the fib sequence. 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, ...

When you put these possible bit strings in order you can make a nuance by deciding which of bit strings you're looking at. The first one is "false", the last one is "true" and the other ones in between are variations on "maybe". Longer sequences are more "nuanced" because there are more maybe values.

This is just the first step in this development, but I've set this up as a new project in the Subversion repository using Maven2.

http://fluidiom.svn.sourceforge.net/viewvc/fluidiom/nuance-engine/

We're going to take this step by step, and the first step for me was to create this first layer in the nuance-engine code. The main bit of code builds the bridge between the Fibonacci delimiter code and the idea of a Nuance. It's called a NuanceInputStream and it takes an input stream of bits and reveals the successive nuances that come out from between the delimiters.

NuanceInputStream.java - read bits and produce nuances

Imagine this input stream eating ones and zeros on the one end, effectively reading the genome, and then producing nuances on the other end. The next step will be to apply these nuances to executing an algorithm in general: nuanced instruction sets. Stay tuned. The first thing I want to apply this to is building structures.

Technorati Tags: evolution artificial life tensegrity darwin binary

First things first. I decided this week to "reboot the world" on the Intelligent Design version of Darwin at Home so that we can once again start from scratch and see new kinds of bodies emerge. If anybody is interested in data-mining, I have a huge archive file with all the XML representation of the different creatures everywhere as they've evolved through the last months. I can imagine that this might be interesting to academics. Let me know if you want it.

Then on to the recent developments. I found myself dividing the tensegrity program into two parts: one of them is a "laboratory" where we have lots of interesting controls to play with, and the other is a "world" where growth and sprouting is starting to happen autonomously and you can travel around a huge space, creating them and watching them grow. It's all in the beginning stages, but both versions have been wrapped into one and put online for you to play with.

Listen to the podcast to hear about tensegrity vulcanization, whereby extra cables are added to stiffen things up.

http://www.darwinathome.org/tensegrity-20080312/

I've been working on this for quite a while, nowadays spending the odd day at the architects' office, and I'm afraid it's difficult for me to leave it alone during evenings and weekends as well. It's so much fun to play around with these tensegrity things and to puzzle out how they actually work. Also, it's good to get the navigation working nicely. What's really encouraging as well is how the architects react when I show them what's developing, because they're very enthusiastic.

Most of the efforts in the last while have been to make sure that it's possible for these tensegrities to kind of grow on their own. To make this happen, I've created classes called Module and Triangle (links below) to represent segments of the tensegrities and the places where new ones can sprout, respectively. A module is capable of sniffing out what triangles it currently has.

• Module.java - represents a three-bar tensegrity module
• Triangle.java - capable of sprouting a new module

To set up something for starters so that tensegrities can grow spontaneously in the "world" version, I've set up a new Life package with mostly Java interfaces that give a carefully limited view of the things that can be manipulated. For example, the "Segment" is implemented by the Module.java below. I'll talk more about these things as they start to take a more concrete form.

By the way, this podcast and the last were recorded using a very tiny and effective device, the iAudio U3. I love the convenience of just using such a little device with no moving parts, and I like the quality enough to keep using it for this.

Technorati Tags: evolution tensegrity darwin

Evolution brings a generative process into contact with a selective process, and before we can do any productive thinking about what might constitute fitness, we have to get the generative process working. Before we can evolve tensegrities we have to be able to grow them, and last time I explained that I felt unprepared to do make the next step, so let's extend this prerequisite: Before we can grow tensegrities we have to be able to build them by hand.

So I took the challenge of putting a new version of Tensegrity online for myself, Hans Moor, and the rest of you to play with so we can all get a real feel for what tensegrity is like. Please take some time to play around with it a bit, and let me know what kind of feeling it gives you and what it makes you think about or what questions come up in your mind.

http://www.darwinathome.org/tensegrity-20080217/

This version is by no means refined to be idiot-proof, so don't expect it to seem finished. I did come up with one really nice interactive feature, and that is the highlighting of triangles where the building will happen. The code for this is quite nice, but of course the way it works is most important: when you see a triangle highlighted, you can click your mouse button and a new tensegrity module will appear! Enjoy experimenting with the program, and let your imagination wander.

Yesterday I once again participated in the very fascinating Biota.org Live radio show podcast and delving into the idea of Intelligent Design with the four other guys and how it applies to ALife developers like us. I talked about how I think it's a perfect description of what we do, and that our artifical life efforts only serve to elucidate the absurdity of the religious notion of Intelligent Design. The challenge that we seem to have taken on is to design intelligently enough that the design becomes intelligent in some way, or in other words to build something that surprises us. I make the point that it's very hard to prove to yourself and to others that you have built something that doesn't need your steering, but it's somehow autonomous instead.

I also mentioned that I'm very reluctant to call something intelligent design or artifical life until it has really surprised me. Currently with this tensegrity project we are not yet even approaching evolution yet. Instead we're still taking steps towards developing the generative growth processes.

One thing that I finally got right this week (actually at 1am saturday morning!) is the physics of the rigid bars when they hit the ground. A while ago I set it up with antigravity below the floor, but that really didn't work well. I kept seeing unwelcome artifacts of the physics appearing, and more recent changes have left me with tensegrities spontaneously scooting across the floor instead of coming down to the surface with a thud. The way I solved the problem was, upon floor collision, to eliminate the component of the other joint's velocity pointing in the direction of the bar. This was exactly the "thud" that was missing. They now act exactly like rigid bars.

Last time I talked about reducing degrees of freedom in the tetra and now the simplicity that this has added to the model is starting to pay off. There's one thing from last time that I got wrong, and that's the name "tension factor". The lower the tension factor the higher the tension so the name just doesn't seem right. A great name for this quantity occurred to me suddenly: "Slack"! The desired length of the four cables in a tetra, added up, divided by the sum of the length of the two bars crossing in the middle is now called slack. I've loved the word slack ever since I came across The Church of the Subgenius. This version has a slider for you to raise or lower the slack, and I recommend you play around with it, probably best with zero-gravity.

Technorati Tags: evolution tensegrity architecture

Another fascinating friday spent talking and coding from a place overlooking the city. It was such a beautiful bright day in Rotterdam I took a picture with my laptop.

Much of the morning was spent talking and exchanging geometrical and architectural ideas with Hans Moor, although It's clear that we're approaching these ideas of evolution from very different points of view.

He doesn't really work with numbers or math, and that kind of things is essential for me to do what I need to do. He thinks about how people will experience the spaces, and how the structure can be made flexible and use space to give people impressions. I'm sure I'll get to that at some point later on, but for now I'm still wrestling with a number of fundamental issues in arriving at a growable tensegrity geometry.

My bottom-up orientation and my concentration on the purity of the mathematical model and the efficiency of the calculations (I need to accelerate time as much as possible!) are far removed from his considerations about how people experience architectural structures. We seem to be building a quite unique bridge between two different worlds, and somehow we both have the intuition that it's going to result in something.

Hans and I talked a lot about the idea of "Intelligent Design", and how the aesthetic of the architecture that might arise from this kind of evolution process is to be found in the economy of the result. We want a kind of fitness function that takes several different aspects into account at the same time, and one of the most important ones is economy! The beauty is in the economy.

It's quite funny because I try and convince Hans that the fitness function will be unable to fully capture what we want these things to become and that his architect intuitions will be needed as a steering force in the selection. This is what I want to call "Intelligent Design", fully aware that this amounts to intentionally co-opting the term from the religious folks. He seems to think that the human role can disappear completely because of that very thing: the beauty is in the economy. It's like we're arguing each others' points.

Diving back into the code after lunch, I tried to explain to Hans what I had been building through the week. My drive is to find just the right ways to reduce degrees of freedom. There are going to be numbers involved, but anything I can do to reduce the number of differnt numbers makes the result that much easier to handle. One main consideration is to create a scenario where no floating-point numbers have to come in from the. The genes will be talking in discrete terms, not in continous terms.

A couple of opportunities for reducing degrees of freedom have convinced me that the direction I took last week fortunately still seems like a good direction, having the Tetra play a central role. Not everyone agrees yet.

In response to last week, David Weston sent me an email with an interesting proposal, pointing to a beautiful video on youtube that I hadn't seen: "I was recently alerted to this tensegrity video on YouTube that shows the construction of a buckyball (truncated icosahedron?) using 30 bows (sticks with thread attached at each end). This video suggests that the basic building block for tensegrity structures is a bow." I've been thinking in terms of the "bow" for a long time, but I no longer think it should be considered central.

I've developed the Tetra idea further to reduce degrees of freedom, giving it a "tension factor" and a "pull vector". The tension factor is the total of the desired lengths of all four cables, divided by the total length of the two bars. The nice thing about this tension factor is that it is independent of size, since it expresses something relative and local to the tetra. The pull vector was also designed to express something relative as well: the different desired lengths of the four cables. The pull vector determines what you might call "the shape of the kite".

You will remember that the tetra is flat if it is not entwined with other ones into a tensegrity, and in this state its bars are crossed. The best image for this is a kite, and a square kite would have a pull vector of ( 1/4, 1/4, 1/4, 1/4 ). Notice that the pull vector is four numbers and it expresses the relative lengths, the total of all four numbers being 1.

Imagine a kite with this pull vector: ( 1/16, 1/4, 15/16, 1/4 ). That would be a kite that is very lopsided, with one very short side. This is the kind of tetra we often see in tensegrities.

So the tension factor and the pull vector can say a lot about the shape of a tetra, and if all tetras in a tensegrity share these values then they determine global features of the tensegrity. That's the way I've implemented to start off. One more thing is that a tetra can have its pull vector shifted around so that a different cable becomes the shortest, so each tetra has a pullVectorOffset with values 0, 1, 2, or 3. I guess it could be flipped too, but I'm leaving that for now.

After I got this all working I started thinking hard again about how to grow tensegrities. If this tetra is the building block then I should be able to just keep adding tetras joining new bars to existing bars. Unfortunately it doesn't quite work that way, unless I come up with some really interesting ways for tetras to kind of "give way" to others because when so many inter-bar tetras are added the tensegrity has just too many cables active. Somehow certain cables should decide not to be active, or something.

Meanwhile, when I showed Hans the basic three-bar tensegrity module wobbling and bouncing around he finds the thing beautiful in its simplicity. Every still-weird tensegrity that I build bigger than that one he finds kind of confusing and ugly. These are useful morsels of input, and exactly the reason I wanted to get involved with architects.

I went and just sat down for a while to think it all through, because I felt paralyzed by not knowing what the next step should be. It didn't look like I could get a tensegrity growing from scratch by just connecting new things to it. Somehow a tensegrity is a "whole" and you can't just think of it in terms of elements, but at the same time I really want this to be a bottom-up evolution of elements. The tetras will have to interconnect, perhaps communicate via their shared bars, and figure out who gets priority and who relaxes their cables, or something. It was kind of like "writers' block". I was sitting there looking at the Maas River and the Erasmus bridge, and I was stuck. Was David Weston's video really suggesting that the bow is central? I couldn't prove it for myself either way.

Then it hit me. This is a feeling I remember from earlier Darwin at Home work. Sometimes it's impossible to imagine how things can be made to "grow" when you don't yet have something working already, almost chicken-and-egg. These 3D tensegrities are almost impossible to draw on 2D paper so it's extremely challenging to think it all through. The intuitions about how to proceed are nowhere to be found! I need to build up the intuition much more: mine, Hans', and people following this development.

I decided that what I need to have is the tools to be able to build tensegrities by hand before I'll be able to understand how to make them grow. Even if the tensegrites initially consist of repeated elements I'm sure that it would be enough to get the mental juices flowing in the right way. So I started programming the things needed to be able to build tensegrities by hand from this basic module. Since modules cannot connect with bars against bars, I had to make the cables such that they are ready to accept connections with bars. Every cable now gets a "middle joint" which is not yet connected to a bar, but it is ready to do just that on command. Here's a screen shot so you can see all the candidate connection points:

I plan to set up the rest of the interaction this week to make building possible and publish a new version on the web so you all can play with it a bit. Imagine the balls halfway the cables in the image above to be "attractive" to the bar ends of a nearby module. This is how they will connect up, like blocks. Each connection is a triangle of bar-end to cable connections.

• Cable.java - Cables now have a middle joint.
• Tensegrity.java - creates and maintains the middles

Technorati Tags: evolution tensegrity darwin