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.

I’ve been working on some designs for custom made wheels for a potential installation project. The aim is to lasercut some light-weight & good looking acrylic wheels and so I’ve been literally searching for a few candidate solutions, which allow me to cut out large pieces of material from inside the wheel to keep the weight down whilst still being sturdy enough (thankfully the load on them will be minimal so I can skip the structural analysis).

Not wanting to do this exploration/hike manually, I opted for the Processing PDF output route and have written this little tool below to show me my options (at least some of them) and also tweak them easily.

Apart from Processing, the tool also makes use of these 3 classes from the toxiclibscore package:

Vec2D

This class, alongside its sibling Vec3D, is likely one of the most used classes of the entire library. Since 1.0 Processing has its own vector class too now, but Vec2D/3D are far more feature complete, implement a fluent interface for more legible code when dealing with complex vector maths and can be faster too (especially for 2D, but also by helping you to avoid temporary object creation). Furthermore Vec2D also has support for polar coordinates (Vec3D has spherical as equivalent) which was very helpful for building the tool below:

Normally, you’d specify a Cartesian point with:

Vec2D v = new Vec2D(x, y);

However, if we want to interpret our vector as polar coordinates, we’re using the x component to specify the radius and the y component as rotation angle. To convert the vector back into Cartesian space (e.g. our screen) we can use the .toCartesian() method…

Vec2D v = new Vec2D(radius, theta).toCartesian();

In a similar manner, you can also transform a Cartesian point into polar coordinates:

// here we 1st create a copy of v and then convert that one
Vec2D p = v.copy().toPolar();

To see this basic usage pattern in more context, take a closer look at the drawHoles() method below (lines 114-134) or check out the PolarUnravel demo bundled with the core lib.

Spline2D

Each cut-out shape in the wheel is created from a simple spline shape, specified using only 4 points. As mentioned above, these anchor points are specified using (initially) polar coordinates and the Spline2D class is then computing control points (handles) for each of these given points automatically. As user you can also specify tightness & subdivisions for the computed curve vertices in between. While the lack of direct manual control over the spline handles might be a shortcoming in some situations, I generally found it easier to work with this automated version, especially when working with long curves and not only single bezier segments.

The next release of the library will also add a decimator method to this class which will enable the sampling of the curve at a uniform interval (i.e. all successive points of the returned list have the same distance (within a tolerance), regardless of curvature). This feature comes from the ParticlePath class briefly described in the Happy 2010 post.

Computing symmetrical handles for the curve endpoints is another still outstanding feature, but currently low priority (unless someone has got a patch ready for that ;)

The next image shows the 4 anchor points of each spline shape in green and all other computed vertices in pink.

UnitTranslator

This class is the sole, lonely member of the toxi.math.conversion package, but is especially useful for those of you using Processing for digital fabrication or creating printed outputs. It provides the following conversion methods, making it trivial to e.g produce PDF outputs at the right physical dimensions (without trial & error):

• millisToPixels(double mm, int dpi) – Converts millimeters into pixels.
• millisToPoints(double mm) – Converts millimeters into PostScript points.
• pixelsToInch(int pix, int dpi) – Converts pixels into inches.
• pixelsToMillis(int pix, int dpi) – Converts pixels into millimeters.
• pixelsToPoints(int pix, int dpi) – Converts pixels into points.
• pointsToMillis(double pt) – Converts points into millimeters.
• pointsToPixels(double pt, int dpi) – Converts points into pixels.

In the demo below, we’re using it to specifiy the wheel radius and drill holes in mm and then automatically calculate the required window size in pixels. In that case we’re however not using millisToPixels(), but millisToPoints() because PDF units are in points which are interpreted as 1 pixel (at 72 dpi)…

The Wheel tool

Just copy & paste the code below into Processing and hit Run to fill up your hard disk (kidding, by default it only generates 120 different small PDF files/variations). The variations are created by iterating over all permutations of 4 parameters: number of symmetry steps, inset radius, core radius, alternate core radius.

/**
 * Generative wheel designs utilizing Vec2D polar coordinates,
 * splines and unit conversion. By default each design is exported as
 * PDF & PNG file, but can be turned off by setting the doExport flag to false.
 *
 * Usage: if export is enabled simply run & wait until all permutations
 * have been generated. Else press 'x' to activate next permutation or
 * use - / = to adjust the ARC_WIDTH parameter which defines the
 * size of the cutouts.
 *
 * (c) 2010 Karsten Schmidt, PostSpectacular Ltd.
 *
 * More info: http://toxiclibs.org/2010/01/re-inventing-the-wheel/
 * Source code licensed under GPL v3.0. See http://www.gnu.org/licenses/gpl.html
 */

import processing.pdf.*;

import toxi.geom.*;
import toxi.math.conversion.*;

// bleed in mm
int BLEED = 6;

// wheel radii & document size
float R = (float)UnitTranslator.millisToPoints(370 / 2);
float W = 2 * R + 2 * (float)UnitTranslator.millisToPoints(BLEED);
float EMPTY_CORE_SIZE = (float)UnitTranslator.millisToPoints(5);

// start number of main segments
int NUM_SEGMENTS = 3;

// normalized parameters
float INSET_RADIUS = 0.8f;
float OFFSET = 0.1f;
float CORE_RADIUS = 0.15f;
float ALTCORE_RADIUS = 0.3f;
float ARC_WIDTH = 0.4f;

// optional mounting holes
int NUM_DOTS = 18;
float DOT_RADIUS = 0.97f;
float DOTSIZE = (float)UnitTranslator.millisToPoints(2);

// number of subdivisions for spline vertex computation
int SPLINE_SUBDIV = 20;

// flag for PDF & PNG export of all permutations
boolean doExport = true;

public void setup() {
  size((int) W, (int) W);
  // turn off automatic redraws when not exporting
  if (!doExport) {
    noLoop();
  }
}

public void draw() {
  String frameID =
    "wheel-" + NUM_SEGMENTS + "-" + nf(INSET_RADIUS, 1, 2) + "-"
    + nf(ALTCORE_RADIUS, 1, 2) + "-"
    + nf(CORE_RADIUS, 1, 2) + "-" + nf(ARC_WIDTH, 1, 2);
  println(frameID);
  if (doExport) {
    beginRecord(PDF, "out/" + frameID + ".pdf");
  }
  background(255);
  noStroke();
  fill(0);
  translate(width / 2, height / 2);
  ellipseMode(RADIUS);
  ellipse(0, 0, R, R);
  fill(255);
  ellipse(0, 0, EMPTY_CORE_SIZE, EMPTY_CORE_SIZE);
  // main holes
  drawHoles((INSET_RADIUS + OFFSET) * R, CORE_RADIUS * R, (INSET_RADIUS
    + OFFSET + CORE_RADIUS)
    / 2 * R, ARC_WIDTH, 0, NUM_SEGMENTS);
  if (CORE_RADIUS >= 0.5) {
    drawHoles(CORE_RADIUS * 0.85f * R, 0.2f * R,
    (CORE_RADIUS * 0.85f + 0.2f) / 2 * R, ARC_WIDTH, 0,
    NUM_SEGMENTS);
  }
  // small cutouts
  drawHoles(INSET_RADIUS * R, ALTCORE_RADIUS * R,
  (INSET_RADIUS + ALTCORE_RADIUS) / 2 * R, ARC_WIDTH / 2, PI
    / NUM_SEGMENTS, NUM_SEGMENTS);
  if (ALTCORE_RADIUS >= 0.5) {
    drawHoles(ALTCORE_RADIUS * 0.85f * R, 0.3f * R,
    (ALTCORE_RADIUS * 0.85f + 0.3f) / 2 * R, ARC_WIDTH / 2, PI
      / NUM_SEGMENTS, NUM_SEGMENTS);
  }
  // drill holes
  drawDots(NUM_DOTS, DOT_RADIUS * R, DOTSIZE);
  if (doExport) {
    endRecord();
    saveFrame("png/" + frameID + ".png");
    nextPermutation();
  }
}

void drawDots(int num, float radius, float s) {
  float delta = TWO_PI / num;
  for (int i = 0; i < num; i++) {
    Vec2D p = new Vec2D(radius, i * delta).toCartesian();
    ellipse(p.x, p.y, s, s);
  }
}

void drawHoles(float outerR, float innerR, float centerR, float radiusWidth, float thetaOffset, int num) {
  radiusWidth *= PI / num;
  Spline2D s = new Spline2D();
  // define point in polar coordinates, then convert them
  Vec2D p = new Vec2D(outerR, 0).toCartesian();
  Vec2D a = new Vec2D(outerR, radiusWidth).toCartesian();
  Vec2D b = new Vec2D(centerR, radiusWidth).toCartesian();
  Vec2D c = new Vec2D(innerR, 0).toCartesian();
  Vec2D d = new Vec2D(centerR, -radiusWidth).toCartesian();
  Vec2D e = new Vec2D(outerR, -radiusWidth).toCartesian();
  // add points to spline & compute
  s.add(p).add(a).add(b).add(c).add(d).add(e).add(p);
  java.util.List verts = s.computeVertices(SPLINE_SUBDIV);
  float delta = TWO_PI / num;
  for (int i = 0; i < num; i++) {
    pushMatrix();
    rotate(i * delta + thetaOffset);
    drawPath(verts);
    popMatrix();
  }
}

void drawPath(java.util.List verts) {
  beginShape();
  for (Iterator i = verts.iterator(); i.hasNext();) {
    Vec2D v = (Vec2D) i.next();
    vertex(v.x, v.y);
  }
  endShape();
}

public void keyPressed() {
  if (key == 'x') {
    nextPermutation();
  } else if (key == '-') {
    ARC_WIDTH -= 0.02;
  } else if (key == '=') {
    ARC_WIDTH += 0.02;
  }
  redraw();
}

void nextPermutation() {
  CORE_RADIUS += 0.2;
  if (CORE_RADIUS >= INSET_RADIUS) {
    CORE_RADIUS = 0.15f;
    ALTCORE_RADIUS += 0.2f;
    if (ALTCORE_RADIUS >= INSET_RADIUS) {
      ALTCORE_RADIUS = 0.3f;
      INSET_RADIUS += 0.1f;
      if (INSET_RADIUS > 0.8) {
        NUM_SEGMENTS++;
        INSET_RADIUS = 0.8f;
        if (NUM_SEGMENTS > 12) {
          exit();
        }
      }
    }
  }
}

Finally, below are some more images of variations created with this tool (see the full size & set on flickr):

I especially like the amount & colours of the contour layers used to visualize different densities. A similar (only in principle) thought also lead to the concept for the V&A Decode Identity completed recently. Just create a VolumetricSpace instance, use one of the preset VolumetricBrushes (or create your own one through sub-classing), use it to manipulate the “density” in the space and then pass the space instance to a IsoSurface to turn it into a TriangleMesh. Et voila! Example code for this basic approach comes with the volumeutils library download.

UPDATE: There’s also an older, alternative version which is using sensor inputs to control its growth (so maybe the above process is related or even the same)…

“this rhizome grows only if PIR sensor doesn’t detect movement [either nobody is in the room, or you stay still] amount of light measured by photocell influences branches girth. in this way, resulting form is a diagram of changing environmental conditions.”