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.

3D warp weighted loom simulation

One of the main objectives of the weavecoding project is to provide a simulation of the warp weighted loom to use for demonstrations and exploration of ancient weaving techniques. Beyond the 4 shaft loom dyadic calculator we need to show the actual process of weaving to explain how the structures and patterns emerge. Weaving is very much a 3D process and these visualisations fail to show that well. It also needs to be able to be driven by the flotsam tangible livecoding hardware so running on a Raspberry Pi is another requirement.

I’ve decided to make use of the Jellyfish procedural renderer to build something fast and flexible enough, while remaining cross platform. Jellyfish is a lisp-like language which compiles to a vector processing virtual machine written in C++, and approaches speeds of native code (with no garbage collection) while remaining very creative to work with, similar to fluxus livecoding. Previously I’ve only used it for small experiments rather than production like this, so I’ve needed to tighten up the compiler quite a bit. One of the areas which needed work (along with function arguments which were coming out backwards!) were the conditional statements, which I removed and replaced with a single if. Here is the compiler code at the lowest level which emits all the instructions required:

```;; compiler code to output a list of instructions for (if pred true-expr false-expr)
(define (emit-if x)
(let ((tblock (emit-expr (caddr x))) ;; compile true expression to a block
(fblock (emit-expr (cadddr x)))) ;; compile false expression to block
(append
(emit-expr (cadr x)) ;; predicate - returns true or false
(emit (vector jmz (+ (length tblock) 2) 0)) ;; if false skip true block
tblock
(emit (vector jmr (+ (length fblock) 1) 0)) ;; skip false block
fblock)))
```

Then I can implement cond (which is a list of different options to check rather than one) as a purely syntactic form with a pre-processor function to create a series of nested ifs before compiling them:

```;; preprocessor to take a cond list and convert to nested ifs
(define (preprocess-cond-to-if x)
(define (_ l)
(cond
((null? l) 0)          ;; a cond without an else returns 0
((eq? (caar l) 'else)  ;; check for else clause to do
(cons 'do (pre-process (cdr (car l)))))
(else (list 'if (pre-process (caar l)) ;; build an if
(cons 'do (pre-process (cdr (car l))))
(_ (cdr l)))))) ;; keep going
(_ (cdr x))) ;; ignores the 'cond'
```

Here’s an example of the if in use in the loom simulation at the ‘top’ level – it gets the current weaving draft value for the weft and warp thread position and uses it to move the weft polygons forward or back (in the z) a tiny amount to show up on the correct side of the warp.

```(define calc-weft-z
(lambda ()
(set! weft-count (+ weft-count 1))
(set! weft-z
(vector 0 0 0.01)
(vector 0 0 -0.01)))))
```

One of the reasons I’m writing about all these levels of representation is that they feel close to the multiple representations present in weaving from draft to heddle layout, lift plan, fabric structure and resulting pattern.

Bumper Crop released

A release of Bumper Crop is now up on the play store with the source code here. As I reported earlier this has been about converting a board game designed by farmers in rural India into a software version – partly to make it more easily accessible and partly to explore the possibilities and restrictions of the two mediums. It’s pretty much beta really still, as some of the cards behave differently to the board game version, and a few are not yet implemented – we need to work on that, but it is playable now, with 4 players at the same time.

The 3D and animation is done using the fluxus engine on android, and the game is written in tinyscheme. Here’s a snippet of the code for one of the board locations, I’ve been experimenting with a very declarative style lately:

```;; description of location that allows you to fertilise your crops
;; the player has a choice of wheat/onion or potatoes
(place 26 'fertilise '(wheat onion potato)
;; this function takes a player and a
;; selected choice and returns a new player
(lambda (player choice)
(if (player-has-item? player 'ox) ;; do we have an ox?
;; if so, a complete a free fertilise task if needed
(if (player-check-crop-task player choice 'fertilise 0)
player)
;; otherwise it costs 100 Rs
(if (player-check-crop-task player choice 'fertilise 100)
(player-add-money player -100) ;; remove money
player choice 'fertilise)
player)))
(place-interface-crop)) ;; helper to make the interface
```

The game on tablet:

This is the game running on a phone:

Evolving butterflies game released!

The Heliconius Butterfly Wing Pattern Evolver game is finished and ready for it’s debut as part of the Butterfly Evolution Exhibit at the Royal Society Summer Exhibition 2014. Read more about the scientific context on the researcher’s website, and click the image above to play the game.

The source code is here, it’s the first time I’ve used WebGL for a game, and it’s using the browser version of fluxus. It worked out pretty well, even to the extent that the researchers could edit the code themselves to add new explanation screens for the genetics. Like any production code it has niggles, here’s the function to render a butterfly:

```(define (render-butterfly s)
(with-state
;; set tex based on index
(texture (list-ref test-tex (butterfly-texture s)))
;; move to location
(translate (butterfly-pos s))
;; point towards direction
(maim (vnormalise (butterfly-dir s)) (vector 0 0 1))
(rotate (vector 0 90 90))      ;; angle correctly
(scale (vector 0.5 0.5 0.5))   ;; make smaller
(draw-obj 4)                   ;; draw the body
(with-state          ;; draw the wings in a new state
(rotate (vector 180 0 0))
(translate (vector 0 0 -0.5))  ;; position and angle right
;; calculate the wing angle based on speed
(let ((a (- 90 (* (butterfly-flap-amount s)
(+ 1 (sin (* (butterfly-speed s)
(+ (butterfly-fuzz s)
(time)))))))))
(with-state
(rotate (vector 0 0 a))
(draw-obj 3))              ;; draw left wing
(with-state
(scale (vector 1 -1 1))    ;; flip
(rotate (vector 0 0 a))
(draw-obj 3))))))          ;; draw right wing
```

There is only immediate mode rendering at the moment, so the transforms are not optimised and little things like draw-obj takes an id of a preloaded chunk of geometry, rather than specifying it by name need to be fixed. However it works well and the thing that was most successful was welding together the Nightjar Game Engine (HTML5 canvas) with fluxus (WebGL) and using them together. This works by having two canvas elements drawn over each other – all the 2D (text, effects and graphs) are drawn using canvas, and the butterflies are drawn in 3D with WebGL. The render loops are run simultaneously with some extra commands to get the canvas pixel coordinates of objects drawn in 3D space.

Many languages: DÃƒÂ¼sseldorf Institute for Music and Media Seminar

Last week was my first official seminar at the DÃƒÂ¼sseldorf Institute for Music and Media with Julian Rohrhuber filling my new role as Associate Professor in Critical Programming. I wanted to start by introducing the cultures and history of programming, with a focus on the people who invented programming languages and what they were doing if for – from the early mathematicians to the military/space industry and in more recent times the rise of JavaScript from a language that would only ever be used for “animating buttons” to the language with widest reach.

With that in mind I wanted to try teaching a fluxus workshop using planet fluxus, the version that compiles Scheme to JavaScript rather than the native code version. This is now working in a new url with quite a lot of fixes and now quite a lot of testing carried out on it. I’m pretty pleased with the support for webgl – and plan to use it for some upcoming games, other than needing switching on with some versions of Safari, it otherwise seems pretty widespread and fast.

My second day of teaching was followed by a presentation by Ellen Harlizius-KlÃƒÂ¼ck and Alex McLean on weaving, ancient mathematics, programming, mythology and music – which provided a great introduction for a meeting we had the next day on an upcoming project bringing these concepts together.

Raspberry Pi: Built for graphics livecoding

I’m working on a top secret project for Sam Aaron of Meta-eX fame involving the Raspberry Pi, and at the same time thinking of my upcoming CodeClub lessons this term – we have a bunch of new Raspberry Pi’s to use and the kids are at the point where they want to move on from Scratch.

This is a screenshot of the same procedural landscape demo previously running on Android/OUYA running on the Raspberry Pi, with mangled texture colours and a cube added via a new livecoding repl:

Based on my previous experiments, this program uses the GPU for the Raspberry Pi (the VideoCore IV bit of the BCM2835). It’s fast, allows compositing on top of whatever else you are running at the time, and you can run it without X windows for more CPU and memory, sounds like a great graphics livecoding GPU to me!

Here’s a close up of the nice dithering on the texture – not sure yet why the colours are so different from the OUYA version, perhaps a dodgy blend mode or a PNG format reading difference:

The code is here (bit of a mess, I’m in the process of cleaning it all up). You can build in the jni folder by calling “scons TARGET=RPI”. This is another attempt – looks like my objects are inside out:

Procedural landscape demo on OUYA/Android

A glitchy procedural, infinite-ish landscape demo running on Android and OUYA. Use the left joystick to move around on OUYA, or swiping on Android devices with touchscreens. Here’s the apk, and the source is here.

It’s great to be able to have a single binary that works across all these devices – from OUYA’s TV screen sizes to phones, and using the standard gesture interface at the same time as the OUYA controller.

The graphics are programmed in Jellyfish Lisp, using Perlin noise to create the landscape. The language is probably still a bit too close to the underlying bytecode in places, but the function calling is working and it’s getting easier to write and experiment with the code.

```(define terrain
'(let ((vertex positions-start)
(flingdamp (vector 0 0 0))
(world (vector 0 0 0)))

;; recycle a triangle which is off the screen
(define recycle
(lambda (dir)
;; shift along x and y coordinates:
;; set z to zero for each vertex
(write! vertex
(vector 1 1 0)) dir))
(write! (+ vertex 1)
(+ (*v (read (+ vertex 1))
(vector 1 1 0)) dir))
(write! (+ vertex 2)
(+ (*v (read (+ vertex 2))
(vector 1 1 0)) dir))

;; get the perlin noise values for each vertex
(let ((a (noise (* (- (read vertex) world) 0.2)))
(b (noise (* (- (read (+ vertex 1))
world) 0.2)))
(c (noise (* (- (read (+ vertex 2))
world) 0.2))))

;; set the z coordinate for height
(write! vertex
(+ (*v a (vector 0 0 8))
(vector 0 0 -4))))
(write! (+ vertex 1)
(+ (*v b (vector 0 0 8))
(vector 0 0 -4))))
(write! (+ vertex 2)
(+ (*v c (vector 0 0 8))
(vector 0 0 -4))))

;; recalculate normals
(define n (normalise

;; write to normal data
(write! (+ vertex 512) n)
(write! (+ vertex 513) n)
(write! (+ vertex 514) n)

;; write the z height as texture coordinates
(write! (+ vertex 1536)
(*v (swizzle zzz a) (vector 0 5 0)))
(write! (+ vertex 1537)
(*v (swizzle zzz b) (vector 0 5 0)))
(write! (+ vertex 1538)
(*v (swizzle zzz c) (vector 0 5 0))))))

;; forever
(loop 1
(set! flingdamp (+ (* flingdamp 0.99)
(*v
(vector 0.01 -0.01 0))))

(define vel (* flingdamp 0.002))
;; update the world coordinates
(set! world (+ world vel))

;; for each vertex
(loop (< vertex positions-end)

;; update the vertex position
(write! vertex (+ (read vertex) vel))
(write! (+ vertex 1) (+ (read (+ vertex 1)) vel))
(write! (+ vertex 2) (+ (read (+ vertex 2)) vel))

;; check for out of area polygons to recycle
(cond
(recycle (vector -10 0 0)))
(recycle (vector 10 0 0))))

(cond
((> (swizzle yzz (read vertex)) 4.0)
(recycle (vector 0 -8 0)))
((< (swizzle yzz (read vertex)) -4.0)
(recycle (vector 0 8 0))))

(set! vertex (+ vertex 3)))
(set! vertex positions-start))))
```

This lisp program compiles to 362 vectors of bytecode at startup, and runs well even on my cheap Android tablet. The speed seems close enough to native C++ to be worth the effort, and it’s much more flexible (i.e. future livecoding/JIT compilation possibilities). The memory layout is shown below, it’s packing executable instructions and model data into the same address space and doesn’t use any memory allocation while it’s running (no garbage collection and not even any C mallocs). The memory size is configurable but the nature of the system is such that it would be possible to put executable data into unused graphics sections (eg. normals or vertex colours), if appropriate.

Jellyfish: A daft new language is born

After trying, and failing, to write a flocking system in jellyfish bytecode I wrote a compiler using the prototype betablocker one. It reads a scheme-ish imperative language and generates bytecode (which is also invented, and implemented in C++) it only took a couple evenings and a train journey to write, and it even seems to work.

The basic idea is to walk through the code tree described by the scheme lists generating bits of bytecode that fit together. Let’s take logical “not” as an example. Like GPU processors, the only datatype is vectors of 3 floats, and we define false as 0 in the x position and anything else in x to be true (ignoring what’s in y or z). There is no single instruction for “not” so we have to build it from the other instructions. For example this bit of code:

```(not (vector 0 0 0))
```

should return (vector 1 0 0). When we are walking the tree of lists we check the first element and dispatch to a set of functions, one for each type of (higher level) instruction which ’emit’s a list containing the bytecode required. The one for ‘not’ looks like this, where x is the expression, e.g. ‘(not (vector 0 0 0))’:

```(define (emit-not x)
(append
(emit (vector jmz 3 0))
(emit (vector ldl 0 0))
(emit (vector jmr 2 0))
(emit (vector ldl 1 0))))
```

The first thing it does is return all the instructions required for the expression we pass in the second element of ‘x’ with ’emit-expr’. With our simple example it will just push (vector 0 0 0) onto the stack, but it could be a whole load of complicated nested expressions, and it will work the same.

After that we have some bytecode:

```jmz 3 0 ;; if top of stack is 0, jump forward 3 instructions (ldl 1 0)
ldl 0 0 ;; load 0 onto the stack
jmr 2 0 ;; jump forward 2 instructions (skip to next code section)
ldl 1 0 ;; load 1 onto the stack
```

So this just checks (and removes) the top element on the stack and pushes the opposite logical value. Pushing a single float like the ‘ldl’ (load literal) instructions above expands to a vector value internally, it’s just a convenience. Some instructions (such as those involving vector maths) are just a single instruction, others like conditionals or loops are a bit trickier as they need to count instructions to skip over variable length sections of program.

We add variables in the form of ‘let’ that map to addresses a the start of memory, read and write for accessing model memory like array lookups. The full flocking system looks like this, and animates a points primitive in OpenGL:

```(let ((vertex 512)
(accum-vertex 512)
(closest 9999)
(closest-dist 9999)
(diff 0)
(vel 1024))
(loop 1 ;; infinite loop
(loop (< vertex 532) ;; for every vertex
;; find the closest vertex
(loop (< accum-vertex 532)
(cond
;; if they're not the same vert
((not (eq? accum-vertex vertex))
;; get vector between the points
(cond
;; if it's closer so far
((< (mag diff) closest-dist)
;; record vector and distance
(set! closest diff)
(set! closest-dist (mag closest))))))
(set! accum-vertex (+ accum-vertex 1)))
;; reset accum-vertex for next time
(set! accum-vertex 512)

;; use closest to do the flocking, add new velocity
;; to old (to add some inertia)
(write! vel (+ (* (read vel) 0.99)
;; attract to centre
(* (+ (* (- (read vertex) (vector 0 0 0)) 0.05)
;; repel from closest vertex
(* (normalise closest) -0.15)) 0.01)))
;; add velocity to vertex position

;; reset and increment stuff
(set! closest-dist 9999)
(set! vel (+ vel 1))
(set! vertex (+ vertex 1)))
;; reset for main loop
(set! vertex 512)
(set! vel 1024)))
```

This compiles to 112 vectors of bytecode (I should call it vectorcode really) with extra debugging information added so we can see the start and the end of each higher level instruction. It all looks like this – which most importantly I didn’t need to write by hand!

```10 30000 0 ;; top memory positions are for registers controlling
512 2 1    ;; program and graphics state (primitive type and number of verts)
nop 0 0    ;; space
nop 0 0    ;; for all
nop 0 0    ;; the variables
nop 0 0    ;; we use
nop 0 0    ;; in the program
nop 0 0
nop 0 0
nop 0 0
;; starting let  <- program starts here
ldl 512 0        ;; load all the 'let' variable data up
sta 4 0
ldl 512 0
sta 5 0
ldl 9999 0
sta 6 0
ldl 9999 0
sta 7 0
ldl 0 0
sta 8 0
ldl 1024 0
sta 9 0
;; starting loop  <- start the main loop
;; starting loop
;; starting loop
;; starting cond
;; starting not
;; starting eq?
lda 5 0
lda 4 0
sub 0 0
jmz 3 0
ldl 0 0
jmr 2 0
ldl 1 0
;; ending eq?
jmz 3 0
ldl 0 0
jmr 2 0
ldl 1 0
;; ending not
jmz 38 0
;; starting set!
;; starting -
ldi 4 0
ldi 5 0
sub 0 0
;; ending -
sta 8 0
;; ending set!
;; starting cond
;; starting <
;; starting mag
lda 8 0
len 0 0
;; ending mag
lda 7 0
jlt 3 0
ldl 1 0
jmr 2 0
ldl 0 0
;; ending <
jmz 12 0
;; starting set!
lda 8 0
sta 6 0
;; ending set!
;; starting set!
;; starting mag
lda 6 0
len 0 0
;; ending mag
sta 7 0
;; ending set!
;; ending cond
;; ending cond
;; starting set!
;; starting +
lda 5 0
ldl 1 0
;; ending +
sta 5 0
;; ending set!
;; starting <
lda 5 0
ldl 532 0
jlt 3 0
ldl 1 0
jmr 2 0
ldl 0 0
;; ending <
jmz 2 0
jmr -72 0
;; ending loop
;; starting set!
ldl 512 0
sta 5 0
;; ending set!
;; starting write!
;; starting +
;; starting *
ldi 9 0
ldl 0.9900000095 0
mul 0 0
;; ending *
;; starting *
;; starting +
;; starting *
;; starting -
ldi 4 0
ldlv 0 0
nop 0 0
sub 0 0
;; ending -
ldl 0.05000000075 0
mul 0 0
;; ending *
;; starting *
;; starting normalise
lda 6 0
nrm 0 0
;; ending normalise
ldl -0.150000006 0
mul 0 0
;; ending *
;; ending +
ldl 0.009999999776 0
mul 0 0
;; ending *
;; ending +
sti 9 0
;; ending write!
;; starting write!
;; starting +
ldi 9 0
ldi 4 0
;; ending +
sti 4 0
;; ending write!
;; starting set!
ldl 9999 0
sta 7 0
;; ending set!
;; starting set!
;; starting +
lda 9 0
ldl 1 0
;; ending +
sta 9 0
;; ending set!
;; starting set!
;; starting +
lda 4 0
ldl 1 0
;; ending +
sta 4 0
;; ending set!
;; starting <
lda 4 0
ldl 532 0
jlt 3 0
ldl 1 0
jmr 2 0
ldl 0 0
;; ending <
jmz 2 0
jmr -160 0
;; ending loop
;; starting set!
ldl 512 0
sta 4 0
;; ending set!
;; starting set!
ldl 1024 0
sta 9 0
;; ending set!
ldl 1 0
jmz 2 0
jmr -173 0
;; ending loop
;; ending let
```