simulation – dave's blog of art and programming

Further attempts at untangling tablet weave

One of the great unknowns following the first weavecoding project was the nature of tablet weave. Other than a few primitive attempts that didn’t work in all cases and lead us to further questions, modelling tablet weave fully was left as an undeciphered mystery. Tablet weave is a complex and particularly ancient form of weaving, while it’s simple to do with easily found materials, it produces a kind of double weave with twisting, and you can create crazy higher level 3D structure as it is free from the constraints of fixed loom technology.

The trick to start understanding this (I still have quite some way to go) came from only thinking about a single square tablet. If we follow the paths of each of the four threads while turning the square 90 degrees at a time we can see how tablet weaving is a combination of a weave (up and down movement) and a braid (left and right), as it twists the threads in relation to each other.

From this sketchy starting point it was possible to create two 3D objects to represent each twist, one for clockwise and another for anticlockwise. If you colour the separate threads appropriately and combine them together you get something like this:

While this looks fancy, it’s wrong. The threads may be in the correct form conceptually, but woven structure comes about as a relationship between the positioning of the threads and the tension applied to them. Many of the threads above should be pulled straight and push others out of the way to give a pattern that was actually straight stripes of colour, rather than chevrons. So how can we add tension?

One way to approach this problem would be to use a physical simulation of the kind usually applied to cloth simulation, and ‘relax’ the the threads to achieve a realistic result, using a stochastic approach to iteratively tighten them within collision constraints, until it ‘looked right’. The problem with this is that it wouldn’t lead to a deeper understanding of what is going on here. This in a way is related to a bigger issue with AI and machine learning, where techniques like artificial neural networks can be trained to solve problems well enough to be useful, for example in speech recognition – but do not provide any new knowledge about language or understanding of deeper scientific issues.

So if we want to understand some of the ‘thread logic’ of table weaving, we are can approach this in a more symbolic manner. Can we add additional straightened threads to our two twisted ones?

As with the twists, there need to be two forms of straightening – left or right twist to straightened threads, and then we need to get back from a straightened thread to a left or right twist.

Notice that some of these shapes connect, while others are incompatible. We can start with the original twisted weave above, and process it to pull the threads straight. In order to do this we need to know the past and future actions of the weaver, or the current twist in the context of those before and after it. This makes sense, as when weaving structure emerges fully a few wefts behind the current one you are weaving – only as the tension is applied to the fabric does it take form.

The rules to describe this turn out to be well represented as a diagram. The nodes are the 3D shapes required and the edges are the actions of the weaver (the special ‘floating’ state change interestingly depends on the action before the last one – memory does seem important in tablet weaving).

For example, we can ‘left twist’ repeatedly (the top right state) as the arrow points to itself. If we start going in the other direction we then need to pass through two straightening states to get to a full ‘right twist’. If we start going backwards and forwards in smaller numbers of turns then more complex things happen.

When we process the first weave with these rules, you can see some of the straightening effects. The tension on the threads means that some cover up others, e.g none of the yellow threads are now visible on the top of the fabric at all.

The structure is more visible here than on a real weaving as the threads are thinner that they would be for the resulting weave which would be more densely packed together (this is less realistic but helps to understand what is going on).

How do we know if any of this is correct? The only way to test this for sure is against real weave. We can try out different sequences of actions and see if the model matches. As indicated above, tablet weaving is a technique that comprises several categories of weaves – these define some specific types of structure we can test.

Type 1: Repeated twists and turn back

Most normal tablet weave consists of twisting repeatedly 90 degrees in the same direction and weaving a weft each time. In practice there is only so far you can go in the same direction before the unwoven warp threads behind the tablets get tangled up, so you need to change direction and go the other way until they are untangled, providing some symmetry to the pattern. The first example has all the tablet threads aligned in the same sequence – and we weave 8 turns one way and 8 turns back again. You can see in the middle when we change direction we create a short straightened ‘float’ section which causes the tension to pull the threads straight here.

One of the further mysteries that our first tablet weaving simulations couldn’t previously recreate were situations where the pattern on the back and the front of the weave were not opposite of each other. This is highly unusual in weaving, but this model seems to represent this correctly. Here the actions are the same as the first example – 8 one way and then the other, but the thread colours in the tablets are offset from one another so they are staggered and you get the diagonal patterns.

Type 2: Single faced double weave

Part of the complexity of tablet weaving is because it is a kind of double weave – there are two intertwined weave structures happening at the same time. If we repeat two wefts of 90 degrees one way followed by two more the other direction, the two weaves remain on the same side of the textile – which can be seen clearly if we colour them appropriately. This example keeps the white weave on the top side with the brown one on the lower side.

Type 3: Degenerate floats

The third type of weave is not really a weave but a breakdown of the process caused by only weaving single 90 degree turns backwards and forwards repeatedly. This means half of the threads are not incorporated into the weave and ‘float’ along the surface on both sides.

While the language to fully describe the tablet weaving has yet to be developed properly, you can have a go yourself with this model which is currently online here (takes a few moments to render at first).

This gets us closer to a working model of tablet weaving, and provides something we can start to use for a more advanced aims of the Penelope project. For example, can we use the pattern matrix to tangibly livecode tablet weaving? Does this make it possible to explore and explain this type of weaving?

If this kind of textile wasn’t complicated enough, people in ancient times combined multiple weaving techniques, for example tablet weaving and warp weighted weaving in the same piece of fabric. Creating a kind of ‘grand unified’ weaving model is an additional future challenge, so we can start to understand better the thought processes involved in these advanced techniques.

Viruscraft: building a ‘reasonably accurate’ genetic game world simulation

The concept for the viruscraft game is to have a realtime genetic model or simulation of the host evolution which is adapting to the properties of a virus you are building (either on screen or via a tangible interface as part of an exhibit). This model needs to be realistic, but only up to a point – it can be more of a caricature of biology than a research model would need to be, as our intentions are educational rather than biological research.

Using our previous species prototype as a starting point, we have a network of connected locations that can be inhabited by organisms. These organisms can jump to neighbouring locations and be infected by others in the same place at the same time. Now we need to figure out how different species of these organisms could emerge over time that evolve immunity to a virus – so we can build up a family tree (phylogeny) similar to the ones we created for the egglab game but that is responding to the viruses that you create in realtime as you play. The evolution itself also has to happen fast enough that you can see effects of your actions ‘quickly enough’, but we’ll worry more about that later.

For a job like this we need to move back from fancy visualisations and graphics and try to get some fundamental aspects working, using standard tools like graphviz to understand what is going on to save time.

The first thing to do is to add a fixed length genetic string to each individual organism, this is currently 40 elements long and is made from biologically based A,T,C and G nucleotide symbols. We chose these so we can use biological analysis tools to test the system as we go along just like any other genetic process (more on that below). The organisms can also reproduce by spawning copies of themselves. When they do this they introduce random errors in the genetic code of their offspring which represents mutation.

Previously we were using a ‘SIRS’ model for virus infection (susceptible -> infected -> recovered -> susceptible), based on 4 global parameters that determined the probability of jumping from one state to the next. Using the genetics, the probability of infection is now different for every individual based on:

1. Is a virus infected individual in the current location?

2. If so, use our genetic code to determine the probability of catching it. Currently we use the ratio of A’s to T’s in the genetic string as a totally arbitrary place-holder ‘fitness function’, the lower the number the better. AAAAAAT is bad (fitness: 6) while TTTTTTA is good (fitness: 0.1666) – so we would expect the A’s to disappear over time and the T’s increase in the genetic strings. This number also determines the probability of dying from the disease and (inversely) the probability of gaining immunity to it.

3. A very small ‘background infection’ probability which overrides this, so the virus is always present at a low level and can’t die out.

The next thing we need is a life cycle for the organism – this needs to include the possibility of death and the disease model is now a ‘SIR’ one, as once recovered, individuals cannot go back to being susceptible again.

All the other non virus related probabilities in the simulation (spawning offspring, moving location, natural death) are currently globally set – to make sure we are seeing evolution based only on disease related behaviour for now.

This model as it is could form the foundation of a world level visualisation – seeing organisms running around from place to place catching and spreading your virus and evolving resistance to it. However this is only half the story we want to tell in the game, as it doesn’t include our time based ‘phylogenetic’ family tree view. For this, we still need to figure out how to group individuals into species so we can fully visualise the effects of your virus on the evolution of all the populations as a whole.

First we need to decide exactly what a species is – which turns out to be quite an arbitrary concept. The rather course approach that seems to work here is to say that two organisms represent two distinct species if more than a quarter of their genes are different between them.

We can now check each organism as it’s born – and compare its genome against a ‘blueprint’ one that represents the species that it’s parent belongs to. If it’s similar enough we add it to its parents species, if it’s too different we create a new species for it. This new species will have a copy of its genome as the ‘blueprint’ to compare all its descendants with. This should mean we can build up a set of related species over time.

If we run the simulation for 5000 time steps we can generate a phylogenetic family tree at the end, using the branch points between species to connect them. We are hiding species with only 1 member to make it simpler, and the population is started off with 12 unique individuals. Only one of which (species 10) is successful – all the later species are descendants of that one:

The numbers here are the ID, fitness and size of population for each species. The colours are an indication of population size. The fitness seems to increase towards the right (as the number drops) – which is what we’d expect if new species are emerging that cope better with the virus. You can imagine changing the virus will cause all this to shift dramatically. The “game mechanic” for viruscraft will all be about tinkering with the virus in different ways that changes the underlying fitness function of the host, and thus the evolution of the populations.

As we used standard biological symbols for our genetic code, we can also convert each species into an entry in a FASTA format text file. These are used by researchers to determine population structure from limited information contained in genetic samples:

> 1 0.75 6 TGCTCTTGCGTACTAGACTGTTGACATCTCCACCGGATAA > 3 0.46153846153846156 5 TGGTTTTCTGCTGTGGGGATAACCTGCCACTCAGTGGTGA > 5 0.6153846153846154 171 CACTATCGCTCATTGCACTGTCGTGGTTTTAGTAACGAGC ...

In the FASTA file in the example above, the numbers after the ‘>’ are just used as identifiers and are the same as the tree above. The second line is the blueprint genome for the species (its first individual). We can now visualise these with one of many online tools for biological analysis:

This analysis is attempting to rebuild the first tree in a way, but it doesn’t have as much information to go on as it’s only looking at similarity of the genetic code. Also 40 bases is not really enough to do this accurately with such a high mutation rate – but I think it’s a good practice to keep information in such a way that it can be analysed like this.

Procedural weave rendering

We’ve been working on new approaches to 3D rendering ancient weaves, using Alex’s new behavioural language (which describes a weave from the perspective of a single thread) as the description for our modelling. This new approach allows us to build a fabric out of a single geometric shape, where warp and weft are part of the same thread.

This is mix of tabby and 2:2 twill, created by this code:

warp 12 24 ++ [TurnIn] ++ threadWeftBy'' Odd (rot 3) ([Over,Under]) 12 12 ++ threadWeftBy'' Odd (rot 3) ([Over,Over,Under,Under]) 12 12

I’m still learning this language, but more on that soon. This line produces an large list of instructions the weave renderer uses to build it’s model, turning the thread and shifting it up and down as it crosses itself.

In the video in his last post Alex describes using this to mix two separate weaving techniques together, which is one of our main reasons for developing this language – existing weave simulations cannot replicate the weaving technology of the ancient Greeks who for example, combined tablet and warp weighted weaving in the same fabric.

The second problem with weave simulations is shown by the following screenshot from a popular existing system:

Fabrics modelled in this way are considered to infinitely repeating sections with chopped off threads. There is no consideration for the selvedge at the edge of the fabric – which as we’ve shown in our past research is almost like a completely separate weave system of it’s own, and rarely considered by notation systems or modelling (and often left to the weaver to ‘livecode’). Here is a different view of the same fabric:

We can also now introduce other changes to the yarn structure, for example modifying the width using a sine wave.

I still have a few glitches to fix as you can see above, but here is a video of the development process from the first script, getting the polygons lined up, fixing the turning, adding over/under, reading Alex’s code and finally lining everything up.

A language for Tablet weaving

After the tablet weaving experiment, here is an attempt at a language/notation for understanding it better. You can have a go here.

Lets start simple:

(weave-forward 16)

The card rotations are shown on the left for each of the 8 cards, the predicted weaving is on the right for the top and bottom of the fabric. This is setup with a double face weaving on square cards, so black, black, white, white in clockwise from the top right corner. (weave-forward 16) turns all the cards a quarter turn and weaves a weft and repeats this 16 times.

We can offset the cards from each other first to make a pattern. rotate-forward turns only the specified cards a quarter turn forward without weaving a weft (rotate-back also works):

(rotate-forward 0 1 2 3 4 5) (rotate-forward 0 1 2 3) (rotate-forward 0 1) (weave-forward 32)

We can’t really weave 32 forward quarter rotates without completely twisting up the warp so lets go forward/back 8 instead to make something physically weavable:


(rotate-forward 0 1 2 3 4 5)
(rotate-forward 0 1 2 3)
(rotate-forward 0 1)
(repeat 4
  (weave-forward 4)
  (weave-back 4))

Now we get a zigzag – if we change the starting pattern again:


(rotate-forward 0 1 2 3 4 5 6)
(rotate-forward 0 1 2 3 4 5) 
(rotate-forward 0 1 2 3 4)
(rotate-forward 0 1 2 3)
(rotate-forward 0 1 2)
(rotate-forward 0 1)
(rotate-forward 0)
(repeat 4
  (weave-forward 4)
  (weave-back 4))

This zigzag matches the stitch direction better. Instead of the rotation offsets we can also use twist, which is more traditional, you can use it to form any pattern. It takes a list of cards to twist, and results in these cards effectively reversing direction compared to the others.


(weave-forward 7)
(twist 0 1 2 3)
(weave-back 1)
(repeat 2
  (weave-forward 2)
  (weave-back 2))
(weave-forward 1)
(twist 2 3 4 5)
(weave-back 1)
(repeat 2
  (weave-forward 2)
  (weave-back 2))
(weave-forward 1)
(twist 1 2 5 6)
(weave-back 1)
(repeat 2
  (weave-forward 2)
  (weave-back 2))

The twist needs to happen when the cards are in the right rotation – if we repeat this example, but change the first (weave-forward 7) to (weave-forward 6) we get this instead:

If we put the twists in the loops, we can make small programs with complex results:


(weave-forward 1)
(twist 0 2 4 6)
(repeat 4
  (twist 3)
  (weave-forward 4)
  (twist 5)
  (weave-back 4))

Coding with threads: Tablet loom

Tablet weaving is an ancient form of pattern production using cards which are rotated to provide different sheds between warp threads. It’s used to produce long strips of fabric, or the starting bands and borders that form part of a larger warp weighted weaving. We’ll come to the second use later in the weaving codes project.

There are quite a few programs around to simulate the tablet weaving process – I used this program to get an initial understanding, here’s an example screenshot:

When using square cards the convention is to name the holes a,b,c,d in clockwise order from the top left corner. The thread that is facing, so creating the colour is shown on the left. This program allows you to choose forward or back 90 degrees at a time for all the cards (the up/down arrows on the right) as well as flipping individual cards (the list of / and \ at the bottom).

To start with I decided to try a double faced weave, using two colours. There is a good site that describes tablet weaving here. I chose this kind of setup as it’s possible to create the warp using 4 continuous threads making it quite fast to get started.

The best weaving technique I found was to attach one end of the warp to a fixed object behind me and the other to a piece of wood I use to maintain tension with my feet, and pushing the weft threads away from me.

There are many different ways to manipulate the cards to affect the structure created, most of the time you rotate all the cards 90 degrees either forward or back between each weft. There is a limit to how far you can go in one direction before the warp behind the cards gradually gets tangled up, so you need to maintain a balance. You can also flip them so they change direction in respect to the others and also the warp becomes twisted differently which affects the pattern. You can also rotate the cards forward and back individually too, although this doesn’t seem to be used much.

Here is a section of the tablet weaving I managed to produce, both sides are shown:

Section A was an attempt at direct pattern control, all the cards are matched up in terms of rotation, but I’m using flipping to change the ‘facing’ colour one by one to manually create a diagonal line. The process I was following consisted of turning forward 90 degrees, one weft, back 90 degrees one weft, then flip the individual cards and repeat. This unfortunately results in a bad structure with long floats.

In section B I tried going forward one more turn before going back two. It took me a while to work this out as it means the same shed (and card configuration) actually creates different colours based on what you did in the previous step – this weaving has a memory! I need to look closer at the structure, or perhaps set up a huge tablet weaving with rope to figure out exactly what is happening here. This structure works much better than A, but notice the jagged edges on part of the diagonal – this is because the pattern is going against the twist direction of the warp in these sections.

Section C is an indirect pattern technique, and much more satisfying – I changed the relative rotation of the cards at the end of section B, then rotated them all together 90 degrees back and forward throughout section C, the change in the pattern is down to the ‘balance’ of backs to forwards. The ‘memory’ effect smooths the pattern, and it always goes with the warp twist, but notice that with this technique the different sides of the fabric have a different pattern, it’s not the inverse – I’m not clear exactly why this is yet.

Dyadic device: a 4 shaft loom simulation.

On the train back from the Sheffield codingweaves workshops back in October I wrote a quick browser program to attempt to further understand the relationship between structure and pattern in weaving – which I’ve put online here. This works in the inverse of how we’ve been writing weaving simulation programs so far. Instead of defining the pattern you want directly, you are describing the set up of a 4 shaft loom – so the warp threads that each of 4 shafts pick up in the top row of toggle boxes, then which shafts are picked up for each weft thread as the fabric is woven on the right.

This involved writing a program that is based closely on how a loom functions – for example calculating a shed (the gap between ordered warp thread) by folding over each shaft in turn and or-ing each warp thread to calculate which ones are picked up. This really turns out to be the core of the algorithm – here’s a snippet:

;; 'or's two lists together:
;; (list-or (list 0 1 1 0) (list 0 0 1 1)) => (list 0 1 1 1)
(define (list-or a b)
  (map2
   (lambda (a b)
     (if (or (not (zero? a)) (not (zero? b))) 1 0))
   a b))

;; calculate the shed, given a lift plan position counter
;; shed is 0/1 for each warp thread: up/down
(define (loom-shed l lift-counter)
  (foldl
   (lambda (a b)
     (list-or a b))
   (build-list (length (car (loom-heddles l))) (lambda (a) 0))
   (loom-heddles-raised l lift-counter)))

I’ve become quite obsessed with this program, spending quite a lot of time with it trying to understand how the loom setup corresponds to the patterns. Here are some example weaves that you can try. Colour wise, in all these examples the order is fixed – both the warp and the weft alternate light/dark yarns.

This is tabby or plain weave – the simplest and strongest weave (used for sails and hard wearing fabric). The striped pattern is a result of this alternating colour order.

Basket weave – doubling the plain weave, results in a zigzag pattern.

This is called 2×2 twill, the structure provides a stretchy fabric, often used for clothes. Notice that the pattern in the same as the basket weave even though the structure is different – this is a hint at how structure and pattern are linked in strange ways (it gets much more complex than this of course).

I’ve become very interested in this threading pattern for the shafts as it results in lots of interesting patterns. This is an example of connected boxes.

A slight shift and we can obtain meanders, an important motif of the kairotic project. It turns out this is a highly unstable structure due to the length of the ‘floats’ – the threads spending too long without being incorporated back into the weave. More on that later on.

Here’s a more freeform weave where I switch patterns between different types by changing the lift order. Much like music, it’s possible to switch patterns in a nice way that doesn’t interrupt the flow.

Next up is building a real loom to try these patterns out in thread form.