Libraries

### OpenGL

Note: Issues with Processing and OpenGL are documented on the Processing Wiki.

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.

Here's a simple example to get you started:

    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;
    }

###### 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).