Libraries

OpenGL

OpenGL (Open Graphics Library) is a cross-platform graphics interface for 3D and 2D graphics. This library allows Processing programs to utilize the speed of an OpenGL accelerated graphics card. This expands the potential for drawing more to the screen and creating larger windows. Processing interfaces with OpenGL through JOGL, an initiative from the Game Technology Group at Sun. You need to have an OpenGL accelerated graphics card installed on your computer to fully utilize this library. For more information, please visit the OpenGL and JOGL websites.

There are no additional methods or fields for this library. It uses the Processing language, but renders geometry differently. Processing is not an IDE for using the JOGL API. We're using OpenGL graphics for one implementation of the Processing Core API.

Programs must import the library using the line import processing.opengl.* and the OpenGL renderer must be specified as the third parameter to the size() function. Software using this library may appear different on varying graphics cards. Some cards support OpenGL better than others.

import processing.opengl.*;

float a; 

void setup() {
  size(800, 600, OPENGL);
  fill(0, 153);
  noStroke();
}

void draw() {
  background(255);
  translate(width/2, height/2);
  rotateX(a);
  rotateY(a*2);
  rect(-200, -200, 400, 400);
  rotateX(PI/2);
  rect(-200, -200, 400, 400);
  a += 0.01;
}
OpenGL Issues

  • Try updating your drivers. If you're getting a blank screen with sketch that uses OpenGL, or the sketch is hanging or starting very slowly, you likely need to update your drivers. Release 0110 and later use a newer version of JOGL, which requires a software update for some video cards. On Windows, updated drivers are available from your machine's vendor, Windows Update, or the manufacturer of your graphics card. On Mac OS X, use Software Update to make sure your system is up to date. For instance, OS X 10.4.2 has problems with 0110+ that are fixed in later releases of 10.4.x.
  • We don't recommend running other OpenGL programs while running Processing in OpenGL mode. GL tends takes charge of things so results will be unexpected (windows from the other app showing through to the Processing window, etc.)
  • OpenGL is really memory hungry because of how textures work. In OpenGL mode, your images as the next power of two larger in either direction. This means an image that's 40x190 pixels will be stored as a 64x256 pixel x 4 bytes per pixel array (along with the original image storage being width x height x 4). This is probably something we can optimize in the future, however no attempt will be made until the surrounding code is debugged. (Bug 150)
  • OpenGL sketches cannot be exported to run in a browser. The export probably won't give an error, but they won't run properly. It's not clear whether this is something that we can fix for the future. OpenGL sketches run on the web starting with release 0113. (Bug 166)
  • If you're getting a blank screen or strange graphics on Windows, try messing with your graphics card settings (or even with a different graphics card). There are lots of options that can cause trouble (if you run into such a situation, please post to the board on how you got it fixed).
  • If you're getting this error on Windows: "net.java.games.jogl.GLException: Unable to enumerate pixel formats of window using wglGetPixelFormatAttribivARB: 0" and your machine has built in "Intel" graphics (this is the case for many Dell machines, for instance) you may just need an updated version of your driver, which can be found here. Of course, read the page closely and make sure that you in fact have this graphics chipset on your machine before installing. Thanks to Daniel Shiffman for finding this fix.
  • On Mac OS X, I don't think there's much we can do about the following error: Error: view not ready, cannot lock focus at "/Users/kbr/JavaNet/jogl/src/native/jogl/ MacOSXWindowSystemInterface.m:createContext:51" that shows up sometimes on Run. Just hit Run again and things oughta work. This may be our bug, but who knows. "Cannot lock focus" bug on OS X is fixed for Processing release 93, thanks to toxi for tracking it down as fixed with a new JOGL release.
  • On Windows, if you're getting a lot of OpenGL crashing, blue screens, or other mess, your driver might be bad (really!) For instance, if you're using a Dell, use the driver they provide (support.dell.com) instead of what might be a more recent driver obtained directly from nvidia.com.
  • When exporting a sketch that uses OpenGL, we only provide the necessary binaries to make the sketch work with Windows (i586), Mac OS X (PPC and Universal), and Linux (i586). There are versions of JOGL that will run on other platforms, such as variants of SunOS or Linux on other platforms (such as amd64). Adding the "JOGL natives" for these platforms along with the default native .jar files that are included with your sketch will enable support for those platforms. More recent releases of JOGL include the JOGL natives files with the web start installation. Download that to get the JAR files for many platforms. The other native binaries can be found on the JOGL web site. Do not use the nightly downloads (they are not "signed", so they won't run in a browser), and make sure that the version matches what's being used with Processing. As of release 0131, this is JOGL 1.1.0.
  • The integrated graphics chipsets that Apple has been using on their "low end" machines (such Intel GMA 950) really stink for OpenGL. Some don't support anti-aliasing at all. These cards are found in the Mac Mini (the Intel version only, the PPC versions had nice graphics), some iMacs, and the MacBook (but no the MacBook Pro). The same chipsets are used in many budget PCs, to which the same disclaimer applies.

Using the OpenGL Renderer - advanced users only!

Generally, this should be only considered a last-ditch way to get at a particular GL-specific feature. It makes your code completely incompatible with everything else (such as future versions of Processing, or other 3D renderers) and will confuse the hell outta people when you post your code to the web. Again, if this works for you great, but if not, we aren't responsible and we will not field questions about it on the board. If you want to write code for Java and JOGL, then find yourself a good Java IDE and get JOGL installed, Processing is probably not the way to do it because that's the kind of confusing mess we're trying to insulate you from.

To get access to the GL object, use the following:

GL gl = ((PGraphicsOpenGL)g).gl;

This will give you JOGL's GL object that talks directly to OpenGL and will let you make OpenGL calls directly.

Again, this is not supported, in the sense that if you get weird problems with a GL-based sketch that uses this method, you're on your own.

Because most of the work in drawing is handled by Processing, most OpenGL calls will not work, because most things won't be set up properly. Therefore, using the GL object may only be useful for tweaking obscure OpenGL parameters.

Another option for talking directly to OpenGL in release 0116 and later is to use the beginGL() and endGL() methods. These were added against my better judgement, and handle setting up the camera matrices (though still no lighting or other parameters). Many features still will not work, but it opens up lots of control for geometry. All the above caveats about "don't cry when it breaks" apply.


import javax.media.opengl.*;
import processing.opengl.*;

float a; 

void setup() {
  size(800, 600, OPENGL);
}

void draw() {
  background(255);
  
  PGraphicsOpenGL pgl = (PGraphicsOpenGL) g;  // g may change
  GL gl = pgl.beginGL();  // always use the GL object returned by beginGL
  
  // Do some things with gl.xxx functions here.
  // For example, the program above is translated into:
  gl.glColor4f(0.7, 0.7, 0.7, 0.8);
  gl.glTranslatef(width/2, height/2, 0);
  gl.glRotatef(a, 1, 0, 0);
  gl.glRotatef(a*2, 0, 1, 0);
  gl.glRectf(-200, -200, 200, 200);
  gl.glRotatef(90, 1, 0, 0);
  gl.glRectf(-200, -200, 200, 200);
  
  pgl.endGL();
  
  a += 0.5;
}

Always do the assignment/cast from g to pgl inside draw(), because 'g' may change from time to time. In addition, use the GL object returned by beginGL() for the same reason, that the GL context itself may have changed. In practice, I've not really seen this happen, but this is strongly encouraged to prevent things from crashing in a bad way (think blue screen/kernel panic kinds of bad ways).