Processing 2.0 was released almost a year ago, and introduced many exciting improvements in several areas. Among those, a new OpenGL renderer with GLSL shader support. Since that time, the shader API – defined not only by the new functions in the Processing language to load and run shaders in a sketch, but also by the set of uniform and attribute variables inside a shader that Processing automatically initializes with the geometry coming from the sketch – has gone some minor changes and tweaks. The reference section in the Processing website, the PShader tutorial, and the built-in examples are all up-to-date, but the last full listing of all the uniform and attribute variables was mentioned in an older post in this blog, and has gone a bit out of date since then. With the recent release of Processing 2.1.2, I could say (with very high certainty) that the shader API in Processing 2 reached a “stable status” and won’t go through any further changes.

I have been interested in projection on spherical domes for a while, but never had the chance to experiment on an actual dome. This situation changed after I met Dave Pentecost a couple of years ago. Dave is an advocate and practitioner of the use of digital domes in education and art, and has been documenting his advances in the development of a low-cost dome authoring and projection system in this website. A dome system following those specifications is being installed at an amazing place in New York, the Lower Eastside Girls Club, a Center for Community for girls and young women on the Lower East Side. The Girls Club has been running since 1996, but recently moved to a brand new building that includes the 30 feet hemispherical planetarium, among many other facilities. A recent visit to the Girls Club’s planetarium allowed me to test the code I wrote earlier for dome projection (and realize that it was wrong), and discuss with Dave how we could use Processing and other software tools to allow people to easily create visual content for domes and to carry out artistic projects specifically tailored to the context of the planetarium. These tests and discussions lead to some recent technical developments that I will describe in more detail below.

Yesterday was a very important day for the Processing project, as a new stable version, “the 2.0”, has been released. This release is the result of the hard work of a small team of volunteers over the course of the past two years, plus the fundamental support and contributions from the entire Processing community. For me, this release is particularly significant since it includes a major rewrite of the OpenGL and video libraries, which represents my main contribution to the project since I become involved in it almost 5 years ago. After a long period of development, it is very satisfactory to reach a point where the code is good enough to abandon the nebulous territory the of alphas and betas. Of course, a stable release like this is also a compromise between imagination and time. Despite of the standing issues that result from that compromise, Processing 2.0 retains all the functionality that turned it into a widely used tool in computational arts, as well as adding new features and improvements that extends its capabilities and also serve as the starting point for future developments. In what follows, I’d like to describe in more detail some of the technical challenges we faced while working on the new OpenGL library, and the solutions attempted in order to deal with those challenges.

Processing 2.0 beta was finally released a couple of weeks ago, with the 2.0b3 version being the latest release in the beta series at this time. The new shader API described in the previous posts (1, 2, and 3) received some tweaking and cleaning-up, so the examples mentioned earlier might not work properly. Check below for a more detailed description of the shader API updates in the beta.
Update: With the release of Processing 2.0 final, some of the contents in this post are outdated, please check this tutorial for a detailed description of the finalized shader API.

This is the last part of a series of posts about the new shader architecture in Processing 2.0. This post focuses on how to integrate low-level OpenGL calls with the standard Processing API. This integration has been possible since very early releases of the 1.0 branch, and allowed users through the use of OpenGL functions to implement advanced rendering functionality not available in Processing. The main drawback of the GL integration in Processing 1.x is that it makes the sketches incompatible with regular Processing code (other 3D renderers for example), and harder to understand by many users. Although the latter will continue to be problem as long as OpenGL calls are explicitly included in Processing sketches, the compatibility issue is addressed by Processing 2.0 now that OpenGL is much more deeply integrated with the P2D and P3D renderers.
Update: With the release of Processing 2.0 final, some of the contents in this post are outdated, please check this tutorial for a detailed description of the finalized shader API.