The Gray-Scott reaction diffusion model is a member of a whole variety of RD systems, popular largely due to its ability to produce a very varied number of biological looking (and behaving) patterns, both static and constantly changing. Some patterns are reminiscent of cell devision, gastrulation or the formation of spots & stripes on furry animals. As with all RD models, these patterns are the result of an iterative process evaluating each cell of the simulation space based on the concentrations of the two main parameters (for Gray-Scott usually named f and K) of the reaction equation as well as taking into account the concentrations of these 2 substances in neighboring cells. So conceptually the reaction diffusion system lies somewhere between the isolated DLA process working with individual particles and the entirely rulebased evaluation of a cell’s neighborhood in traditional cellular automatas, which we will deal with in the next post.

The image below, by Robert Munafo, is a fantastically helpful map of possible patterns resulting from various combinations of the f and K coefficients. Click the image to go to his website and explore the parameters in more detail (there’re close-ups and videos of all interesting combinations).

As with the other classes of the simutils package, the GrayScott implementation comes with several small demos to help you get started. The most basic use case (HelloGrayScott) is just setting up a simulation with default parameters and then allows you to draw in the simulation space with the mouse. Each frame, the reaction is updated, its new state translated into grayscale pixels and then rendered to the screen. The important thing to know here is that there’re 2 separate results states available, normally called the u and v buffers.

GrayScott gs;

// create a new simulation instance
// the "false" refers to a non-tiled space with walls
// set to true to create tiling patterns
gs=new GrayScott(width,height,false);

// configure the simulation params to:
// f=0.023, K=0.074
// diffusion speed for u buffer = 0.095
// diffusion speed for u buffer = 0.03
gs.setCoefficients(0.023,0.074,0.095,0.03);

The main draw() loop then just does this:

void draw() {
  if (mousePressed) {
    // set cells around mouse pos to max saturation
    gs.setRect(mouseX, mouseY,20,20);
  }
  loadPixels();
  // update simulation by 10 time steps per frame
  for(int i=0; i<10; i++) gs.update(1);
  // read out the v buffer and translate into grayscale colors
  for(int i=0; i<gs.v.length; i++) {
    float cellValue=gs.v[i];
    // the cell values in v are usually in the range 0.0 .. 0.33
    int col=255-(int)(min(255,cellValue*768));
    // use the col value for red, green and blue and set alpha to full opacity
    pixels[i]=col<<16|col<<8|col|0xff000000;
  }
  updatePixels();
}

To avoid this manual pixel pushing and enable us to make some of the subtle changes of densities more obvious, we can also use the handy (and also new) ToneMap class of the colorutils package. This allows us to map a number range to different positions (colors) on a multi-color gradient and so potentially better visualize the different densities. The basic usage of this class is shown below:

import toxi.color.*;

ToneMap toneMap;

// define a color gradient by adding colors at certain key points
// a gradient is like a 1D array with target colors at certain points
// all inbetween values are automatically interpolated (customizable too)
// this gradient here will contain 256 values
ColorGradient gradient=new ColorGradient();
gradient.addColorAt(0, NamedColor.BLACK);
gradient.addColorAt(128, NamedColor.RED);
gradient.addColorAt(192, NamedColor.YELLOW);
gradient.addColorAt(255, NamedColor.WHITE);

// now create a ToneMap instance using this gradient
// this maps the value range 0.0 .. 0.33 across the entire gradient width
// a 0.0 input value will be black, 0.33 white
toneMap=new ToneMap(0, 0.33, gradient);

Now we can refactor our Gray-Scott rendering code into something even simpler:

for(int i=0; i<gs.v.length; i++) {
    // take a GS v value and turn it into a packed integer ARGB color value
    pixels[i]=toneMap.getARGBToneFor(gs.v[i]);
}

Btw. The ToneMap class is a nice example of the whole reusable “building block philosophy” of toxiclibs (and the object oriented approach in general). The class is simply a composition of other library classes and under the hood delegates everything to these elements:

All other GrayScott demos, as well as all Cellular Automata examples, make use of this ToneMap class, so do have a look at those for more reference…

Since a homogeneous configuration of the entire sim grid will always just provide one particular character/patterning, the GrayScott class has been designed with extension in mind. The CustomGrayScott demo shows how to impose a pattern on the actual simulation parameters themselves, so that cells at different positions are evaluated using different parameters:

class PatternedGrayScott extends GrayScott {

  // our constructor just passes things on to the parent class
  PatternedGrayScott(int w, int h, boolean tiling) {
    super(w,h,tiling);
  }

  // this function is called for each cell
  // to retrieve its f coefficient
  public float getFCoeffAt(int x, int y) {
    // here we only take the x coordinate
    // and choose one of 2 options (even & odd)
    x/=32;
    return 0==x%2 ? f : f-0.005;
  }

  // this function is called for each cell
  // to retrieve its K coefficient
  public float getKCoeffAt(int x, int y) {
    // here we only use the y coordinate
    // and create a gradient falloff for this param
    return k-y*0.00004;
  }
}

Instead of using the default GrayScott class, we only need to change one line in the setup() method to use our extended version instead:

GrayScott gs;

void setup() {
	size(200,200);
	gs=new PatternedGrayScott(width,height,false);
	...
}

The result of this is shown below… Easy, huh? :)

Having this mechanism in place, it can be also used to create more interesting types of masking. For a commission to produce a cover design for Print Magazine in 2008, I generated a type face from simple line & arc segments and used it as mask to manipulate the concentrations of the f & K parameters to achieve two different types of patterning: one for the inside of the letter shapes, the other for the outside…

The frames of that animation were then stacked up along the Z axis in 3D space and with the help of the volumeutils classes turned into 3D mesh, exported as STL format (also see TriangleMesh.saveAsSTL()) and finally fabricated into the physical, 3D printed sculpture shown below. In a way, the sculpture can be seen as a map of its entire creation process…

Here’re some more rendered detail shots of the sculpture. More information about this project is here and the related flickr set.

Finally, the GrayScottImage demo shows another supported technique of using the library: the seeding of the simulation using a bitmap image.

Diffusion limited aggregation

Diffusion limited aggregation, DLA in short, is a theoretical process describing the clustering of particles through a process of diffusion, like a random walk/Brownian motion. Inspired by the work of Andy Lomas with this process, in 2006 I set out to implement DLA myself from scratch, in order to apply it to structures and literally grow objects not made out of triangles/polygons. At the same time I’d also just discovered the possibilities of rendering huge point clouds with Sunflow, which seemed the perfect combination to explore this all further. By March ’07 I had a system in place which allowed me to grow type and have used it for a commission to produce the “New Shoots” title sequence for Channel4.

The basic premise of a DLA simulation is the slow formation of complex structures through the (random) movement of single particles. Once a particle comes close to an existing one, it attaches itself and a new particle is spawned in a sphere around a previous particle. The process then repeats, slowly filling up the simulation space. If the random walk ever takes a particle passed a certain escape radius, the search is restarted with a different initial direction until another particle is hit. Because particles are usually very tiny, a large number of them and even more iterations are required for even very simple structures to emerge. For example, the final frame of the New Shoots sequence consisted of 4.5 million particles, whereas the structure for the image below has a “mere” 645,000…

Finding the needle in the haystack

Searching for particle collisions in sets of such size linearly is super slow & cumbersome, so to make the process more efficient, my version of DLA is using the PointOctree class from the core package. This class is recursively (and on-demand) subdividing the simulation space into smaller, nested cubes, which are stored as tree structure. When new particles are added by the DLA process they’re also being attached to the leaf nodes of the octree. When the next particle is searching for collisions with existing particles, these can then be found very quickly by querying the octree based on local search criteria using these 2 methods:

PointOctree octree = new PointOctree(new Vec3D(-50,-50,50),100);
List<Vec3D> points; // in Java
java.util.List points; // in Processing, no support for generics!

// search within a sphere (i.e. all points within a certain distance)
Sphere boundingSphere = new Sphere(new Vec3D(),1);
points = octree.getPointsWithinSphere(boundingSphere); // or
points = octree.getPointsWithinSphere(origin, radius);

// search within an axis-aligned bounding box
AABB boundingBox = AABB.fromMinMax(new Vec3D(-1, -1, -1), new Vec3D(1, 1, 1));
points = octree.getPointsWithinBox(boundingBox);

For more usage information about the octree also see the DLASpiral demo (the screenshot below also shows the adaptive structure of the octree) and the OctreeDemo of the core package…

In the future I’ll probably refactor this current dependency on the PointOctree class and have the DLA merely depend on a more generic SpatialTree interface, which then can also be implemented by other tree types, e.g. a kD tree. To compensate, the DLA class so far has an extension point of sorts to allow custom PointOctree sub-classes to be used. In this case you’ll simply have to also sub-class DLA and overwrite the createOctree method to return an instance of your custom PointOctree.

Guided growth

In the above screenshot you can also see the blue spiral shape guideline directing the growth of the particles. These guidelines can either be individual line segments or points lists, e.g. sourced from a Spline3D instance or computed otherwise. When passing in a list of points, they’re connected into successive line segments internally. At least one line segment is required for the DLA process to function and you’d combine the 2 classes like this:

// define a spline
Spline3D spline = new Spline3D();
spline.add(new Vec3D()).add(new Vec3D(0,-50,0)).add(new Vec3D(50,0,50)).add(new Vec3D(0,50,0));
DLAGuideLines guides = new DLAGuideLines();
guides.addCurveStrip(spline.computeVertices(8));

// setup DLA in a cubic space of 100 units edge length (always centred around (0,0,0))
DLA dla = new DLA(100);
// assign guideline(s)
dla.setGuideLines(guides);

The moment the guidelines are attached, each line segment is sampled at a high resolution and the computed points added to a second octree kept by the DLA class. It’s these points which are shown in the above screenshot (although only 10% of them are displayed)…

Order of growth

By default the growth of the entire particle system will be in the same order as the guideline segments have been added, however you’re free to change this by means of custom Compatators. The DLAGuideLines class is storing DLASegment instances in a sorted TreeSet. The order of this set can be defined by defining a custom comparator implementation when creating the guidelines and so any possible growth order can be designed/defined. The example below defines one which enforces a bottom-up growth (assuming positive Y is up):

// define comparator
// (this how to do in Processing, which doesn't support generics...
// in plain Java you'd compare Line3D instance directly
// without the need for casting from Object)
class BottomUpOrder implements Comparator {
  public int compare(Object a, Object b) {
    float ya=((Line3D)a).getMidPoint().y;
    float yb=((Line3D)b).getMidPoint().y;
    if (ya<yb) return -1;
    if (ya>yb) return 1;
    return 0;
  }
}

// now use the comparator for the guidelines
DLAGuideLines guides = new DLAGuideLines(new BottomUpOrder());

The next release of this package will contain a few more of those…

Parameters of growth

The final requirement for the whole process to start is a set of configuration parameters. Of these there are many and so they’re encapsulated in their own class. To use them they’re simply passed to the DLA like:

// use default configuration
dla.setConfig(new DLAConfiguration());

The default configuration has the following values, also briefly described below:

// threshold distance below which a particle attaches itself to an older one
float snapDistance = 1.8f;
// threshold distance to attach to a curve/guideline particle
float curveAttachDistance = 2;

// max. radius of the sphere in which a new particle is spawned around a previous one
float spawnRadius = 12;
// max. radius of the sphere when the particle's random walk is interrupted/restarted
float escapeRadius = 36;
// actual size of the particles (currently assumed to be uniform for entire system)
float particleRadius = 0.25f;
// stickiness factor, only 10% of all attachments will be successful
float stickiness = 0.1f;
// using guidelines the growth can be forced into a certain direction
// this parameter defines the impact strength of this direction
// if 0.0 particles grow in all directions, 1.0 = actual segment direction is used
float curveAlign = 0.74f;

// percentage amount to progress along segments after each new particle
float curveSpeed = 0.00045f;
// velocity of the random particle walk
float searchSpeed = snapDistance * 0.66f;
// turn speed when particle changes direction
float particleSpeed = 0.001f;

// progress speed when scanning guidelines to build octree
float guideLineDensity = 0.1;

// chance for existing/already processed segments to continue growing
// evaluated before spawning each new particle
float continousGrowthRatio = 0.1f;

Why a library?

Whereas this is setup creates very interesting structures (especially when rendered in Sunflow), my idea for this library was not necessarily to have everyone replicate this specific look over & over again, but provide the means to focus more on exploring the actual growth process, to customize it and use it as driver for creating new structures in which the actual particles are only present indirectly/secondary. One key feature for that matter are events emitted by the DLA class at key moments of the process. The DLAEventListener interface defines the following 3 event hooks:

public interface DLAEventListener {

    void dlaAllSegmentsProcessed(DLA dla);

    void dlaNewParticleAdded(DLA dla, Vec3D p);

    void dlaSegmentSwitched(DLA dla, DLASegment s);
}

You can subscribe to these events by either creating your own class implementing this interface or sub-classing the also supplied DLAEventAdapter (in case you don’t want to react to all of them):

class MyDLAListener extends DLAEventAdapter {

  // only get notified when growth is complete
  public  void dlaAllSegmentsProcessed(DLA dla) {
     System.out.println("done");
  }
}

DLA dla=new DLA(100);
// attach listener
dla.addListener(new MyDLAListener());

Alternatively, listening to “new particle” events allows you to construct elaborate structures not just from particles, but use particle positions to deposit small meshes or use volumeutils to draw with a VolumetricBrush at these positions… There’re endless possibilities for further exploration and I hope some of you are excited enough to explore them! If so have fun & share it!

Some more of my own earlier explorations into this field are on flickr.