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…

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.

Edited in a non-stop 24h session, I’m really happy with the result & seeing these projects together in one piece gave me an immense buzz, but see for yourself!

We will be attempting to do another one of these later this year, so if you have built anything cool with any of the library packages you’d want to contribute, please do get in touch here, via email, flickr, vimeo or twitter.