So just like last year’s effort, I’d very much wish for and would like to produce another showreel of all the recent interesting projects & experiments done by YOURSELVES with the various library packages. The aim of this undertaking is simply to create a record, a snapshot, some overview and inspiration for other (possibly new) users of these libs. To make this happen I really do need your help & generous contributions in the form of footage, both video and still image assets. Finished projects are desirable, but often the work-in-progress stages are highly interesting too, so if possible, please do include these too. All work will be clearly credited and the reel will be premiered during my talk at Flash On The Beach on September 27, 2010. Afterwards the video will be hosted on Vimeo.

Like last year, the guidelines are remaining as follows:

• only submit projects you’ve worked on/own rights to/have permission to include
• project name, client (if any), year, author(s), project URL
• list of toxiclibs package(s) used
• video resolution 1280×720 (if possible, lower res might be fine too)
• screenshots/photos (if you have stills only, more than one would be extremely helpful)
• (optional) your vimeo username for crediting using their system

Please get in touch via email: toxiclibs at postspectacular dot com

I can provide FTP upload space if you don’t have any yourself. Alternatively, you might want to sign up with Amazon S3, Dropbox, Box.net or similar services…

Entry deadline is: Monday 20 September 2010, 12:00pm GMT

Your help is v.appreciated & I shall thank you dearly!!!!

Once more for the record, here’s the previous reel from 2009…

Having connectivity information for each vertex, edge and face of the mesh allows for a whole wide range of new, exciting applications and my first exploration on this front deals with various subdivision and mesh smoothing strategies and their use as generative modeling tools… I’m currently developing an extensible architecture to make this system as flexible as possible and you’ll be able to create your own custom strategies to decide about the location of new vertices, but without having to deal with any of the actual subdivision complexities itself, like splitting edges & faces. The same interface pattern thinking is also applied to mesh smoothing and currently I’ve implemented Laplacian smoothing and am working on other options as well…

All this should be very interesting for all users with a more architectural background, but IMHO has also lots of potential for those creating digital fabrication tools. If you have any interest in this and/or some useful pointers to share, please do get in touch!

Pending further testing, this new mesh structure and support architecture will available in the next release (0020)…

The mesh in the video and the examples below are using normal shading to help verifying the correctness of the edge/face splitting algorithm. Each vertex is tinted using its normal vector XYZ components interpreted as RGB color intensities.

These following images show a displacement-subdivided cube with (right) & without (left) mesh smoothing applied…

Some slightly older experiments from the early stages of developing the system. These meshes started out as a simple 8-point cube, subdivided 4-5 levels and then rendered as VBOs with standard gouroud shading…

Mark these dates in your calendar: July 12-18th 2010 – It’s going to be a whole 7 long days of code crafting in the north of Portugal and I’m looking very forward to it! The workshop is limited to 14 participants. Bookings are handled by the University and should be done via their special website. Thank you dearly!

The planned outline is below the poster I made for this unique occasion, so please do read on:

The general idea is to split our time into 4 days of intense tutorials and hands-on examination of core principles & techniques of the computational design approach in the context of creating “generative identities”, without prescribing too much what shape & form these should take. Part of our workshop’s remit is also to enquire the current possibilities. The final 3 days will then be used to build your own project(s) to be use for the Olhares de Outono festival later in November.

The topics listed below are not set in stone and we’ll decide as group on what to focus (much depends on the skills & interests of the participants). Similarly, if you’d like to experiment/include external devices into your project (Wiimote, Arduino), please bring them along. The workshop space is equipped with iMacs, but there’re also a couple of spaces to use your own machine as well… At the end of the workshop, we all should have at least one completed (if not polished) project for the festival, and should strive to document it (the project) too.

Day 1: Getting ready

Processing

• recap of basics
  • types
  • structures
  • working with libraries
  • exporting

• scope
  • learning curve
  • use as environment (PDE)
  • use online vs. offline
  • use as library in larger frameworks
  • P5 within the bigger picture
    • JavaScript
    • Java (Android)
    • OpenFrameworks
    • Cinder

Toxiclibs

• Overview
• Recent updates
• Philosophy
• Resources
• Use cases
• Exercises
  • Key techniques/classes
  • Layering processes/Combining modules
  • Easier handling in Processing

OOP

• Concepts
  • Interfaces
  • Inheritance
  • Polymorphism
  • Encapsulation

• Best practices
  • Events
  • Architecture
  • Design patterns
  • Anti patterns
  • Reusability
  • Open source

Eclipse

• overview
• project setup
• using Processing as lib only
• editor features
  • code completion
  • navigation
  • refactoring

Day 2: Working with data

Data modelling/processing

• Collections
  • Hashmaps
    • Histograms:
      • Images, FFT
      • Tag clouds
  • Lists
    • Iterators
  • Queues
    • Priority based processing
    • Pipes
    • Stacks
  • Trees
    • recursion
    • sorted sets using comparators
      • sort by custom criteria
      • spatial subdivision (quadtree, octree etc.)

• XML
  • standard formats
    • Atom
    • RSS
  • code generation from data model
    • XML Schema
    • JAXB
  • Defining your own formats
    • Loading/saving app state
    • Presets
    • Configuration

• • Aggregation
    • merging of sources and/or time samples
    • set theory
      • union
      • intersection
      • difference
      • relationships (1:1, 1:N, N:M)

Visualisation

• basic graph theory
• finding & creating metaphors
• techniques
  • geometry basics
  • coordinate systems
    • spherical (Geomapping example)
    • polar (color transforms)
    • cartesian
  • vector maths
  • mapping/geometric transformations
    • M->N dimensions
    • time -> space
  • mesh generation
• animation
  • interpolation curves
  • state transitions
  • viewport changes
    • transformation matrix
    • camera control (e.g. 3rd person camera)
• exporting data
  • high res bitmap
  • PDF
  • image sequence + automatic FFMPEG assembly
  • 3D data for digital fabrication

Day 3: Interactions

Building on previous day exercises

HCI

• Wiimote
• Mobile
• Computer vision
• TUIO / OSC
  • • multitouch
    • reacTIVision
    • external devices
• QRCodes
• Location triggers
  • GPS/compass based AR
• Serial input
  • Firmata

Machine-machine interactions

• asynchronous event handling
  • twitter updates
  • reacting to Pachube sensor data
• multi-threading
• network communications/protocols
  • UDP
  • OSC

Day 4: Generative techniques

Building on previous day exercises

Processes as design tools

• inputs
  • observation
  • abstraction
  • mental model building
• behaviour
  • parametrization
  • rules
  • feedback
• simulation
  • agents
  • automata
  • erosion
  • fluids
  • particles
  • physics
• randomness
  • balance of control
  • bias
  • chaos vs. determinism
  • role of authorship?
  • techniques & differences

Day 5-7: Work on own projects

Process

• If possible form pairs/groups
• 2 reviews/status reports/discussion per day with all
  participants
• Karsten giving help & support to all groups
• Final review and presentation on Sunday PM
• Project documentations

And once again, please head over to this site for further organisational things & the signup form…

On April 23 & 24, 2010 I’ll be teaching an advanced Processing, Eclipse & toxiclibs workshop as part of the Processing Paris activities organized by the talented Mr. Webster & David Abouna-Tomé from OFFF.

The Memory Tree

During the 2 days of the advanced Processing Paris workshop we will create an interactive installation called The Memory Tree. The installation will consist of a large projection of a generative, slowly growing 3D tree whose leaves are all made up from messages/thoughts left by visitors and workshop participants.

These messages can either be submitted as voice via mobile phones, Skype or IM, but will also be harvested automatically via tagged content from Flickr and Twitter. The tree will grow and become more complex with every new message collected and so slowly form a browsable history of its creation during the workshop, but also document the reactions of exhibition visitors. Visitors can interact with the installation via a mouse (or Wiimote, if we’re quick…) to change the view of the tree, zoom in, and focus particular messages/images or play recorded voice messages. There could also be a mode where the user directs a “cursor” freely between the various tree branches and listens to all voice messages associated with leaves in the cursor’s proximity. This playback would use 3D audio so that when the focal point is moved, the recorded voices move around in space accordingly and are creating an immersive audio collage. Voices closer to the cursor will play louder than ones further away.

The installation concept will nicely combine a number of different concepts, technologies and programming techniques. It’ll also educate participants about the distributed nature of technologies available and the importance of open standards acting as technological glue between them.

Scope

Amongst other things, we will cover:

• core 3D geometry techniques: vectors, matrices, quaternions, cameras, curves, texture mapping
• complex mesh creation with volumetric modelling
• working with OpenGL
• dealing with parallel processes using multi-threading
• working with 3rd party libraries (mainly from toxiclibs.org)
• multi-channel audio playback
• working with XML efficiently (using JAXB)
• parsing RSS/Atom feeds (Flickr, Twitter integration)
• working with (and creating) REST based web services
• designing an application data model
• object oriented architecture as key enabler for flexible designs

The installation will be obviously using Processing as core platform, however we will use Eclipse as development environment to make development faster, easier and more efficient. Participants should have a medium/firm grasp of Processing and feel comfortable with experimenting with new concepts & techniques with a looming deadline.

If you want to sign up for this, please head over to: processingparis.ning.com

The images are above and below are some very early explorations of a deterministic random 3D tree generator. I’m currently working on a proof-of-concept of some of the above ideas, mainly in order to help us be as efficient as possible on these two workshop days…

The images below are showing the combination of the generated tree structures above with volumeutils to create 3D meshes of the trees…

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.

First up is Ricardo Sanchez, one of those guys who had been hindered by the lack of demos & documentation last year and has been in touch a few times about the physics engine. His questioning also directly triggered me to do a few more demos, which are now bundled with the last couple releases. A few days ago he excitedly told me that he’s finished his project and I wanted to share it with you here too:

You can download the Processing source code for this sketch from the project website and read some more about his process on his blog.

The other experiment I found is a nice showcase of the SphereConstraint in action to create a, well spherical, boundary for the physical simulation space. FYI the constraint can also be inverted and be configured to work as obstacle instead, not allowing any particles within the volume of the sphere. This can be achieved via a flag to its constructor.

The effect is quite interesting and somewhat reminds me of Mikkel Koser’s & shiftControl’s recent COP15 identity, although the behaviour of particles there is far more complex.

More detailed info about the most recent release and the behaviour changes it caused will be posted asap.

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):

By Joe Turner

By DieTapete

By Stefan Mylleager

By Lia

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