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 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.”

So over the holidays I’ve been doing some research about kinetic & mechanical art and then started working on some additions to various classes in the core and physics packages. These in turn needed testing and inspired me to create the little New Year’s greetings below:

Amongst other things the new additions include:

• ParticleString class to automatically connect a list of particles with springs or create a string of particles along a line/ray
• ParticlePath is extending Spline2D/3D and can turn the spline into a ParticleString sampled at an uniform interval
• New ParticleContstraint implementations and improvements to existing ones:
  • AxisConstraint locks movement of a single axis
  • PlaneConstraint locks movement in a plane (only 1 axis left to move in freely)
  • CylinderConstraint creates a cylindrical obstacle in the simulation space
  • BoxConstraint turns an axis-aligned box (AABB) into an obstacle
  • SoftBoxConstraint uses an AABB as perimeter and slowly forces particles towards its centroid coordinates (per axis)
• Reworked (corrected) velocity handling and accessors for contraints to manipulate particle velocities upon collision

Even though these updates are not yet part of a new release, you can download the source code (as complete Eclipse project incl. compiled versions of the pre-release libraries) and interactive realtime versions for OSX & Windows from here:

xmas.postspectacular.com/2010/

To get the project into Eclipse, simply use the Import wizard:

File > Import… > Existing projects into workspace > Next > Select archive file > Choose the downloaded zip > Finish

Apart from the showing how to use these new classes mentioned above, Processing heads might also be interested in the elegance of XML parsing using JAXB (one of my favourite additions to Java 6). Last but not least, the project is also utilizing the custom vector shape alphabet system originally developed for the onedotzero festival identity last year.

Happy 2010 everyone!

The Processing source code for generating these meshes is available with the library download, with an excerpt shown also below. But first, here’s a brief overview of how to use these classes:

Waves & oscillation in general are very flexible & powerful tools for many different design tasks and shouldn’t always be thought of in an audio context. For example, a square wave can be used to flick between 2 values at a given frequency, without the need for any if() statements. I also often use sine waves to create cyclical, soft, harmonious value changes, be it for interface design, movement, animation or even the time based modulation of behavioural parameters of agents. The core library comes with the following pre-defined wave types:

• Sine (pure, frequency modulated (FM), amplitude & frequency modulated (AMFM))
• Sawtooth (FM)
• Square (FM and FM with harmonics)
• Triangle (FM)
• Constant (only provides a static value, e.g. useful as static source for input as FM)

All of these types are expressed as implementations of the AbstractWave class in the toxi.math.waves package. This abstract class defines all commonalities of what constitutes a wave: a phase, a frequency, an amplitude, a centre offset and a bunch of accessors and converters. The actual wave function then needs to be implemented by a concrete sub-class. Using poly-morphism and having an abstract super class makes a lot of sense in this case, since it allows for all this:

1. It frees our main application from having to know which exact wave type we’re going to use and so allows for easier/faster experimentation and generally more flexibility.
2. It enables us to plug-in any of the available wave types as input for frequency or amplitude modulation and so create highly (theoretically infinitely) complex waveforms.
3. It provides the basics of an extensible framework for creating new wave types.

These points are hopefully confirmed by you when looking at this method below (taken from the AdditveWaves demo, bundled since toxiclibscore-0015):

AbstractWave createRandomWave() {

  AbstractWave result=null;

  // create a randomized sine wave to be used as
  // FM input for the main wave chosen below
  // the order of parameters is:
  // start phase, frequency (in radians), amplitude, offset value
  AbstractWave fmod=new SineWave(0, random(0.005, 0.02), random(0.1, 0.5), 0);

  // pick a random frequency
  float freq=random(0.005, 0.05);

  // choose a wave type
  switch((int)random(7)) {
  case 0:
    result = new FMTriangleWave(0, freq, 1, 0, fmod);
    break;
  case 1:
    result = new FMSawtoothWave(0, freq, 1, 0, fmod);
    break;
  case 2:
    result = new FMSquareWave(0, freq, 1, 0, fmod);
    break;
  case 3:
    // harmonic square waves are created by
    // adding sine waves upto a number of octaves
    // above the base frequency
    result = new FMHarmonicSquareWave(0, freq, 1, 0, fmod);
    ((FMHarmonicSquareWave)result).maxHarmonics=(int)random(3,30);
    break;
  case 4:
    result = new FMSineWave(0, freq, 1, 0, fmod);
    break;
  case 5:
    AbstractWave amod=new SineWave(0, random(0.01,0.2), random(2, 3), 0);
    result = new AMFMSineWave(0, freq, 0, fmod, amod);
    break;
  case 6:
    result = new ConstantWave(random(-1,1));
    break;
  }
  return result;
}

The next snippet then quickly shows how this method would be used:

import toxi.math.waves.*;

AbstractWave wave=createRandomWave();

// updates the wave phase and computes the new function value
// this code doesn't care which wave type we're dealing with
float currValue=wave.update();

The generators have another useful feature, though: A state stack. If you’ve used Processing or OpenGL before, you have likely come across the concept in the form of pushMatrix()/popMatrix() calls to save and restore the state of the graphical transformation matrix. The wave generators implement the same idea and so can be easily used to create the 3D meshes above.

// save current wave state
wave.push();

for(int i=0; i<10; i++) {
  float lookahead=wave.update();
  // do something clever
}

// restore wave to previous state
wave.pop();