The joys of Processing @ onedotzero

Dates: 26 & 27 November 2011 (10am – 5pm)
Location: BFI Southbank
Limit: 20 people (TBC)
Level: Beginner
Price: TBC

This year marks the 10th anniversary of Processing and onedotzero are doing their bit to help celebrating this occasion with a weekend workshop and public panel discussion as part of this year’s festival at the BFI Southbank.

In this 2-day weekend workshop we will explore how we can use Processing to express ourselves in code form and create small audio-visual performance tools, both reactive & interactive. You’ll be introduced to creating 2D & 3D shapes and compositions dynamically, play back samples, create complex animations by adding behaviours, export animations as video and control your code using external inputs (e.g. microphone, webcam, OSC/MIDI). There will also be a panel discussion following the workshop on Sunday evening.

Tickets will go on sale later this week via the BFI box office. Please note that BFI members will get priority!

Digital fabrication with Processing & toxiclibs

Dates: 3 & 10 December 2011 (10am – 6pm)
Location: Metropolitan Works, Whitechapel
Level: Intermediate
Limit: 20 people
Price: £175

Arthur Mamou-Mani, lecturer in the Architecture department at University of Westminster and London Metropolitan University, recently approached me to run a workshop around using Processing & toxiclibs for digital fabrication. Using the facilities at Metropolitan Works, we will be applying generative & parametric design approaches to work with different physical materials (2D & 3D) and fabrication techniques (laser cutting, CNC and 3D printing) and refine these explorations into a small, custom design tool, complete with graphical user interface. These high level topics will also include a discussion about using the different material constraints as guiding factors for our design process and learn how to use extensible software structures to customize and combine existing solutions to our specific needs.

We will introduce you to all those concepts in a learning-by-doing manner, but since this workshop only has a 2-day duration, you’re encouraged to prepare yourself beforehand (in the interest of the whole group) and familiarize (not become proficient!) with the following topics:

• Processing syntax & environment
• Check out some of the examples bundled with toxiclibs
• Learn about basic geometry concepts (coordinate systems, vectors etc.)
• Object oriented thinking

For more details & booking, please head over to the workshop page on Arthur’s website.

If you have any questions about either workshop, please add a comment below! Thanks & hope to see you soon!

toxiclibs roadmap Q4/2011 - Q2/2012 (click to enlarge)

A bit of philosophy

From the very outset, the creation of design oriented, composable and reusable data structures and algorithms for manipulating them has been the main aim of this project and also one of the most obvious counter approaches to the way people traditionally work with Processing (hitherto the most used environment for the libs). Even though the majority of classes provided by toxiclibs can have a visual representation, there’s a strict exclusion of any rendering related code in the core packages of the library, since these often carry a vast amount of secondary dependencies, eventually binding the library to a large, rigid environment. Me not likey. Almost all toxiclibs classes are “pure” models which can be queried, transformed, combined and otherwise manipulated as abstract entities. They’re usable as a tool for solving (design) problems, not only for drawing. They are the M in MVC. If one of them ever needs to be drawn/rendered, a 3rd party component is required (the V in MVC, e.g. Processing or straight OpenGL), but toxiclibs does not prescribe how this drawing should be done (but it provides optional tools to support that task). This separation of concerns really has been the #1 feature aimed at making it as easy as possible (and encouraging) to enter this next stage of the project: systematically porting to other languages.

Polyglot toxiclibs

JavaScript

In the past, myself and other people have done half-baked attempts to port selected classes to other languages (ActionScript, JavaScript, C++). However, all of them were just isolated fragments needed for specific projects and never approached general library status even closely. As most people are surely aware of by now, since the beginning of the year Mr. Kyle Philips has been doing a stellar effort systematically porting large parts of the toxiclibs core and physics classes to JavaScript and due to the popularity of that language this port is gaining huge traction. That’s exactly what I’ve been hoping for to happen as an eventual consequence of the above design points, so I’m super happy to see this effect kicking in. JavaScript however does not only mean in-browser usage, even though in combination with WebGL and libraries like three.js & Processing.js the number of potential use cases is huge (I’d say even more so than in the traditional Processing tied context). JavaScript’s reach is massive and it also has deservedly gained traction outside the browser as general purpose language (largely thanks to V8 based platforms, like Node.js, but also Dean McNamee‘s Plask as a more related example). I think toxiclibs can contribute and actively support new developments on these platforms.

In terms of similarity and porting, JavaScript is one of the closest things to Java there is, but it also has unique deployment issues and there’s some substantial organizational effort needed to create a better system for splitting the codebase into modules and integrating the JS port with existing coding standards (CommonJS) and module managers/loaders (e.g. NPM, RequireJS), incl. to start thinking about adopting Google Closure conventions to harness the optimizations achievable by that compiler (e.g. dead code removal, a huge benefit for large libraries as this).

Good API design requires a clean, consistent ethos, a worldview and opinion which not only is carried through and made visible throughout a project, but also leads users of that API to write their own software in a certain/similar manner. To achieve that goal is often a long, winding road and takes much longer to get right than writing actual code, but I think by now, toxiclibs does provide a decent set of consistently used patterns (excluding a few edge cases). Having such a familiar set of classes & APIs available in multiple languages is a serious benefit for users and makes it much easier to experiment & switch between environments, and that without forcing users to stay in a sandbox of sorts (e.g. as ProcessingJS does). I think, having a familiar API too needs to be complimented & balanced with the unique features, idioms and development practices of the host language to allow both code & coder live up to their full potential. For JS these differences are still relatively harmless, but even there we should embrace them more.

Clojure

Ever since college, I had an ongoing, if usually fleeting, fascination with Lisp and its seemingly alien, stripped down approach to syntax, its obsession with brackets and generally doing things “the way round”, at least compared to common (imperative) languages. I never considered Lisp as a serious contender for my own development arsenal until earlier this summer, when I stumbled across Clojure, a modern dialect of Lisp running on the JVM (get a detailed feature overview on their website, it’s worth reading). This time I immediately was struck by its elegance, the resulting concise code and the many other features this language brings to the table, especially for working with collections, data processing & concurrency. Many data munging tasks can be solved in approx. 30-50% code than in Java/Processing, very useful for dataviz. So I made an effort to get into it more seriously. Then I read this article and when I hit this quote, I felt in very similar shoes:

“Many extremely intelligent people I knew and had much respect for were praising Lisp with almost religious dedication. There had to be something there, something I couldn’t afford not to get my hands on! Eventually my thirst for knowledge won me over. I took the plunge, bit the bullet, got my hands dirty, and began months of mind bending exercises. It was a journey on an endless lake of frustration. I turned my mind inside out, rinsed it, and put it back in place. I went through seven rings of hell and came back. And then I got it.

The enlightenment came instantaneously. One moment I understood nothing, and the next moment everything clicked into place. I’ve achieved nirvana.”

Similar to Scala, Clojure compiles directly into JVM byte code and therefore provides comparable speed and can easily interoperate with the vast amount of Java libraries available. Unlike Java, Clojure is focused on immutable data and provides a functional approach to computing, an antidote to living a kingdom of nouns. Common to all Lisps also is the REPL, offering livecoding features as part of the core development process. Lisp/Clojure code is data is code. I don’t need to point out, how exciting this is for people in our field. Besides that though, my main excitement is about the forward thinking take on concurrency/multicore support (agents/futures/atoms/refs) and the ability to easily create domain specific languages. Community activity around the language seems to be glowing hot and is sporting an impressive ecosystem of libraries and amazing support tools, making open source development true fun. Some noteworthy introductory links, should you feel inclined to give it a spin too:

• Clojure – Functional programming for the JVM
• The Joy of Clojure
• Casting Spels in Clojure
• learn-clojure.com
• 4clojure

ClojureScript

ClojureScript is a recent addition to the Clojure ecosystem and potentially something to keep watching closely for the purposes of porting: Clojure compiled into JavaScript. I know it sounds like herasy, but in some respects it seems ClojureScript does “better” JavaScript than the original, providing all the intelligent language features of Clojure (e.g. namespaces, destructuring, function overloading, atoms, macros) and generating JavaScript in a format targeted to Google’s Closure compiler, allowing for vastly better optimizations of large applications than handwritten JavaScript (which can only fully utilize the compiler if you stick to the necessary conventions in ALL your code). I’m in no position yet to actually back any of that with my own experience so far, but it’s an exciting development for sure. Here’s also a video of the launch event of ClojureScript at Google: Rich Hickey (creator of Clojure) unveils ClojureScript and the official announcement with more links.

Keeping in sync & documentation

The next major set of tasks related to porting is figuring out ways to keep the different ports in sync or at least better document which parts of the library are available in which port. For that purpose, I started prototyping a new web app (WebNoir + CouchDB) which will collect metadata from the different source codes and automatically produce a port coverage/sync report. Kyle started manually producing a top-level version of this for his JS port, but its granularity is only at class level, whereas we really do need that information per function/method to be truly useful. This is also because there are still some areas of the original Java version, which will receive further updates and bug fixes and at current there’s no system to mark those places in the code as needing to be reflected in the other ports. Serious development of this tool is top priority after v0021 is out.

Related to that also is documentation, the historically slowest evolving aspect of the whole project. One of the comments I hear most often is “Javadocs suck”. They suck even more so, since for many library classes they’re not even existing or if so only superficially. So in a way I couldn’t agree more, but then again, for the past four years these libraries have largely evolved around my own needs and client projects and I’ve relied on users to consult the 95+ examples bundled with each release (or attend my workshops) in order to learn the basic usage patterns. Whilst I still believe the latter (learning by example) is by far the most efficient way of learning (having done so my entire career), I also think things can be vastly improved by offering documentation in several formats, all cross-referenced between: actual running examples with source code, a literate programming style doc system (e.g. Docco/Marginalia based, very good for workshops) and the traditional javadoc style, for integrating the docs in an IDE setup.

Example output of running an early(ier) Clojure porting effort through Marginalia to produce nice, easy to read documentation next to source code.

IMHO the reason Javadocs are soooo unsuccessful amongst Processing users is actually largely down to the lack of Javadoc support in the Processing PDE. If people would use IDEs like Eclipse showing Javadocs in-situ within the editor context by simply hovering over class names, I believe people would see them for what they really are: kind of awesome!

Eclipse screenshot with Javadocs in editor context.

So in conjunction with the task of adding metadata to every method of every public class in the codebase, all methods will also be receiving full documentation. These docs will then also link to existing examples using the particular method. This will be the second main focal point of the v0022 release (the one after next).

Versioning & repositories

Speaking of version numbers: Again, due to the organic and isolated growth of this project and my own past development practice, the linear versioning scheme was quite sufficient for now. As we all learn new things and our development tactics change, so too will the versioning for this project have to change to something more meaningful. Enter semantic versioning. The idea is nothing new and I’ve been using it for most other projects in the past, but I think this time the reasoning behind it is somewhat different:

1. Currently there’s toxiclibs support for 2.1 languages (the Clojure port is not quite there yet to fully count)
2. Development outside the Processing IDE is far more dependent on build management tools, open source repositories and module managers (e.g. Maven, NPM, Leiningen)
3. Different projects are created at different times and might require different versions of the libraries and
4. I’d really love to get to a point where there’ll be synchronised releases in order to reduce build & documentation complexity and avoid confusion for users so that they can assume v1.0.0 of a module will contain the same features in all (sup)ported languages.

Semantic versioning is the lowest common denominator between all current module managers/repositories and hence will be introduced with the next release. As a result, users will have a much easier way to integrate the libraries into their own (non-Processing) projects, since they will also be available via the major existing open source repositories for the various languages (Sonatype [Java/Maven], NPM registry (JS), Clojars [Clojure/Leiningen]). Apparently, Processing 2.0 will feature its own centralized library management system, but from what I gather it will not offer any integration with any of these existing open source repositories.

New website & tutorials

The current WordPress based setup is not the best platform for integrating all the planned new documentation, tutorials and other features like the bundled example & user galleries. I’ve been test driving Confluence on a private dev server and found this more promising (at least for the documentation & tutorial side), so I might adopt this in the near future. The other (more appealing) alternative is to extend the new CouchDB based sync/doc tool into a more generic web app and add wiki & blogging features. The main issue for that will be increased hosting costs, which I will need to think about more how they can be better balanced. The new website will also host as many of the bundled examples as possible, effectively deprecating the current gallery on openprocessing.org, which is impossible to batch update and therefore can’t reflect any API changes in older examples (which causes unnecessary comments). To better integrate community contributions, that new system will also be used to provide a user gallery.

Furthermore, if you’re like the amazing Amnon Owed, and feel like creating super useful tutorials for the libraries, please start doing so. Any help on increasing the number of learning resources would be an amazing contribution to this project and will play a major role on the new site. Speaking of tutorials, I really do think there also is a big need for a general knowledge tutorial about how to make the most of open source libraries like this from a user perspective and encourage people to contribute (even if in the most indirect ways). Much of the feedback and comments I receive, hints at a large knowledge gap about how to even go about finding out (in a self guided manner) about existing resources, updates, work with the source code, work with issue trackers etc. This generally seems to be a far bigger problem with users in the Processing camp than I’m aware of from other environments. Food for thought!

Summary & next steps

Well, this is the closest thing to a sharable master plan as I could get to for now. Before most of these things will/can be addressed, other minor tasks need to be completed to get 0021 out of the door first. A brief, non-exhaustive overview of new features is here:

• Initial support for NURBS curves and surfaces is the biggest new addition and still requires some more testing and internal restructuring. Supported operations are:
  • Curve builders for circles, arcs and creating curves from a list of points, joining curves
  • Surface builders: extrude curve, revolve curve, construct surface from a grid of points/control mesh
  • Convert surface into TriangleMesh instance (variable resolution & UV coordinate generation)
• Several important additions to the Polygon2D class:
  • construct regular polygons from a given base line segment (useful for creating tesselations)
  • rotate/scale/translate polygons
  • pick random points within a polygon (useful for color sampling)
  • retrieving edge list
• Tesselate polygons using Delaunay triangulation with flexible grid resolutions
• Addition of ConvexPolygonClipper to clip a polygon to the shape of another
• New BezierCurve2D/3D classes in addition to existing Spline2D/3D
• Implementing Visitor pattern for PointQuadtree/PointOctree
• Adding UV coordinate generation to SurfaceMeshBuilder
• Adding PLYWriter for exporting 3D meshes in Standard Polygon format
• ToxiclibsSupport line drawing now supports decorators for dashed lines and arrow heads (customizable)
• Custom DXFWriter for 2D shapes with DXF layer support
• Improving precision/reducing rounding errors for VolumetricBrush
• Adding FluidSolver3D

There’re also a ton of other smaller additions and bug fixes plus approx. 10-15 new examples. Let me also point you again to the repository of workshop projects at learn.postspectacular.com, which contains also several larger projects than the examples bundled with the release.

Showreel

A few people have been asking about sending in stuff for this year’s showreel. Of course, I do intend to produce one again (it’s one of the highlights of the year), though I can only realistically get to this in Nov/Dec, hopefully making it a nice video for the Holiday season. I will send out a proper call for submissions in the next month, but if you have stuff ready, please send it along already. Specs will be the same as previously: Video assets 1280×720 (if possible), still images are fine too and of course please add some brief description & credits.

Any feedback, suggestions & help offers are highly appreciated! So long…

In the meanwhile, I’ve been doing my best to respond to concrete issues & tasks people were trying solve on the Processing forums as well as the issue tracker. The list of demos on OpenProcessing has grown too. And thanks to personal heroes of mine, like Golan Levin, Daniel Shiffman and their students, there’re also a number of very interesting student projects this year, which are utilising the libraries and (in some cases) have their code explorations shared (like good citizens tend to do :). A round-up post of these will follow shortly.

Speaking of missing examples and small projects, teaching workshops has been another well under-documented effort of mine. For most of them, I’ve created a Mercurial repository on this website and I’d encourage you to download and play with these examples as well. A lot of them are more advanced than the examples bundled with each release, some utilize 3rd party libraries and all are generally full of comments, not just about library specific topics. Please also send your virtual thanks to all the unis & institutions allowing this material to be shared!

Workshop repositories: http://learn.postspectacular.com/hg/ – All source code is LGPL licensed unless stated otherwise.

Before I get to the compiled list of mini-tutorials and discussions from the Processing forum, Amnon Owed has recently produced two excellent tutorials for this project and I sincerely hope his efforts will inspire other users to follow suit:

Working with toxiclibs, part #1 (polygons, voronoi explosions)
Working with toxiclibs & Processing, part #2 (physics, colors, zoomlens)

List of recent forum threads (including lots of source code), sorted by subject:

Interaction, events, multi-threading

iPad, TUIO & particles with dynamic attraction behaviors
Custom Events + Event listener?

Geometry

How to use the Toxiclibs Voronoi class?
2D Collision detection – irregular shapes (computer vision blobs)
Octree Visualization
PerlinNoise to specified target destination
What does Vec2D.heading() in Toxiclibs do exactly?
How to calculate the tangent line of a circle?
Mouse within a certain area
using toxiclibs geomutils to solve the “pulley problem”

Geo location (Twitter & Flickr)

GPS to spherical coordinates with Vec3D & toxilibs
GeoLocation Twitter Search: Twitter4j
Simple mapping of geolocated tweets

Color

Working with toxiclibs & Processing, part #2
Question on toxiclibs colorutils Histogram

Rendering

GLGraphics + Toxiclibs Volumeutils (also see post on codeanticode)
Drawing a dotted/dashed arc
Library with box(x,y,z) function?

Math

Can toxi Spline2D be use for more than Vector positions?
convert 0.54321 to 0.54 and convert 2 to 100

XML (JAXB)

These two threads are about JAXB, which is indirectly referenced by various toxiclibs geometry types in order to store them as XML. In anyway, many users are interested in data visualization and JAXB is lightyears ahead of the default XML library bundled with Processing…

JAXB tutorial: XML parsing with style
JAXB tutorial question

Last, but not least: If you have any similar questions, interest in running workshops at your university/company or any small tutorials to share, please do get in touch! ¡Muchas gracias!

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…

UPDATE!!! Entry deadline is: Thu 23 Sep 2010, 09:00 GMT 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…

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…

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.

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

To make the project as widely accessible as possible to people, it was built in Processing, but obviously with a major helping of various toxiclibs too(core, color & volumeutils).

You can download, remix & recode the original piece and turn it into your own original artwork by downloading the app and/or source code from:

decode.googlecode.com

Some of these recoded versions might then even become the new Decode identity. Media partner, CBS Outdoor will be promoting the exhibition using the original piece across its large HD projection screens in platforms on the London Underground from Monday, November 30, 2009. All recoded works submitted via the V&A website before January 11, 2010 will then be put forward into a competition to appear in an advert on CBS Outdoor’s XTP screens, further promoting the exhibition.

UPDATE: I’ve posted some of my favourite “recodes” over here.

Some more images of the whole design journey are on flickr…