WebGL 2 Development with PicoGL.js, Part 1: The Triangle

triangle

This post is part of the series WebGL 2 Development with PicoGL.js.

Welcome to our first lesson! As with any graphics tutorial, the first thing we need to do is get a triangle on the screen.

Environment

First a bit of set up. To get started we’ll need the following:

Throw the two libraries into a directory on your machine, and create an HTML file named part1.html. Run your server and navigate to the correct URL to view the page (default is localhost:8000/part1.html for SimpleHTTPServer, localhost:5000/part1.html for nano-server). It’ll just be a blank page, but we’ll fix that shortly.

Add the following boilerplate code to the HTML file and save:

<!DOCTYPE html>
<html>
<head>
    <script src="picogl.min.js"></script>
    <script src="gl-matrix-min.js"></script>
</head>
<body>
 <canvas id="webgl-canvas"></canvas>
 <script>
   var canvas = document.getElementById("webgl-canvas");
   canvas.width = window.innerWidth;
   canvas.height = window.innerHeight;
 </script>
</body>

This code is what we’ll start with for all of our examples. All we’re doing is loading our two libraries, grabbing a handle to the canvas, and then making it fill the entire page.

PicoGL.js Setup

Now, we get to our first line of PicoGL.js code. Add the highlighted lines to the in-page script:

var canvas = document.getElementById("webgl-canvas");
canvas.width = window.innerWidth;
canvas.height = window.innerHeight;

var gl = canvas.getContext("webgl2");

var app = PicoGL.createApp(canvas)
.clearColor(0, 0, 0, 1);

The first thing we’re doing here is creating a PicoGL.js app, which manages all GL state for us. The second method sets the clear color for the app. Before drawing a frame, we’ll generally want to clear whatever was rendered on the previous frame. This sets the color we’ll use for clearing. It’s an RGBA value, with each channel having a range of [0.0, 1.0], so the color we’re setting here is solid black.

Just to make sure everything’s working properly, add the following line to the end of the script:

app.clear();

If everything’s working correctly, your canvas should be rendering solid black. If so, go ahead and remove that line.

Ok, now let’s actually draw something meaningful. PicoGL.js encapsulates a draw command in a draw call object. At a minimum, a draw call requires a program and a vertex array to function. Let’s look at those two pieces individually.

Create a Program

A program is the combination a vertex shader, to position geometry, and a fragment shader, to color pixels. These function similarly to their WebGL 1 counterparts, but in WebGL 2, we can use GLSL ES 3.00, which is much more powerful than GLSL ES 1.00. Add the following to the HTML page above the script we’re currently working on:

<script type="shader/vertex" id="vertex-shader">
    #version 300 es

    layout(location=0) in vec4 position;
    layout(location=1) in vec3 color;

    out vec3 vColor;
    void main() {
        vColor = color;
        gl_Position = position;
    }
</script>
<script type="shader/fragment" id="fragment-shader">
    #version 300 es
    precision highp float;

    in vec3 vColor;

    out vec4 fragColor;
    void main() {
        fragColor = vec4(vColor, 1.0);
    }
</script>
<script>
    var canvas = document.getElementById("webgl-canvas");
    // ...etc.
</script>

The vertex shader will pass the input position on as a clip position, and will pass the input color on to the rasterizer. The fragment shader simply renders the interpolated value of the input colors. Most of this should be familiar to those who have worked with WebGL 1 and GLSL ES 1.00. There are, however, a few important differences to note:

  • GLSL ES 3.00 shaders must begin with directive #version 300 es.
  • attribute variables have been replaced by in variables and can be given a specific location. This will later allow us to match them up to locations in vertex array objects.
  • varying variables have been replaced by out variables in the vertex shader and in variables in the fragment shader.
  • There is no longer a built-in gl_FragColor variable in the fragment shader. You have to declare the output yourself as an out variable. (Note that you can’t use the name gl_FragColor, since the gl_ prefix is reserved in GLSL.)

With our shader code in place, we can create a program as follows:

// ... etc.
var app = PicoGL.createApp(canvas)
.clearColor(0, 0, 0, 1);

var vSource = document.getElementById("vertex-shader").text.trim();
var fSource = document.getElementById("fragment-shader").text.trim();
var program = app.createProgram(vSource, fSource);

Note that the trim() method here is important! GLSL 3.00 requires that the #version directive be on the first line, which isn’t the case for our script, since we have a newline after the opening script tag. We should now have a program that’s ready to be used for drawing. We just need to define an actual shape to draw. This is where vertex arrays come in.

Create a Vertex Array

The first thing we need to do is set up the vertex buffers we’ll use to store per-vertex attributes. Vertex buffers function essentially the same way they do in WebGL 1. The following code will create vertex buffers for our triangle’s vertex positions and colors:

// ... etc.
var program = app.createProgram(vSource, fSource);

var positions = app.createVertexBuffer(PicoGL.FLOAT, 2, new Float32Array([
     -0.5, -0.5,
     0.5, -0.5,
     0.0, 0.5
]));

var colors = app.createVertexBuffer(PicoGL.FLOAT, 3, new Float32Array([
     1.0, 0.0, 0.0,
     0.0, 1.0, 0.0,
     0.0, 0.0, 1.0
]));

The first buffer stores the 2D coordinates of our triangle. The second stores the RGB values of the colors for each triangle vertex. This should all be quite familiar to those coming from WebGL 1. The next step is slightly different though, in which we’ll bundle our buffers into a vertex array:

// ... etc.
var positions = app.createVertexBuffer(PicoGL.FLOAT, 2, new Float32Array([
     -0.5, -0.5,
     0.5, -0.5,
     0.0, 0.5
]));

var colors = app.createVertexBuffer(PicoGL.FLOAT, 3, new Float32Array([
     1.0, 0.0, 0.0,
     0.0, 1.0, 0.0,
     0.0, 0.0, 1.0
]));

var triangleArray = app.createVertexArray()
.attributeBuffer(0, positions)
.attributeBuffer(1, colors);

Vertex arrays are a small but convenient addition to WebGL 2 that allow you to bundle the state of several attribute buffers and their pointers into a single vertex array object, then simply bind that vertex array, rather then having to set up the individual buffers and pointers for each draw call. Note that we’re passing indices to the attributeBuffer() calls. These indices connect the vertex buffers to the layout locations we gave our in variables in the vertex shader.

We’re now just about ready to…

Draw!

With our program and vertex array ready, we now have everything we need to create a draw call:

// ... etc.
var triangleArray = app.createVertexArray()
.attributeBuffer(0, positions)
.attributeBuffer(1, colors);

var drawCall = app.createDrawCall(program, triangleArray);

And finally, we can draw our triangle:

// ... etc.
var drawCall = app.createDrawCall(program, triangleArray);

app.clear();
drawCall.draw();

If everything went well, you should see the triangle at the top of this post rendering on your screen. Congratulations on creating your first PicoGL.js app! For reference, the competed example for part 1 is available here. Feel free to post any questions you might have in the comments or on the PicoGL.js Gitter chat room!

WebGL 2 Development with PicoGL.js

3D-texture

WebGL 2 is a substantial update to the WebGL API that requires a deeper understanding of the graphics pipeline than was necessary for WebGL 1. Many of the new features require manually ensuring that handles and memory are correctly laid out so that the pipeline can use them efficiently, but this setup can fail in subtle ways that can be difficult to debug.

PicoGL.js is a small WebGL 2 library with the modest goal of simplifying usage of new features without obscuring the functioning of the GL. The constructs one works with are the constructs of the GL: vertex array objects, vertex buffer objects, programs, transform feedbacks. PicoGL.js simply provides a more convenient API for interacting with those constructs, manages GL state, and also provides workarounds for some known bugs in WebGL 2 implementations.

This tutorial series will provide an introduction to WebGL 2 development though PicoGL.js. While I will try to fully describe the concepts that will be discussed, this series might be challenging for those with no graphics background. I’d recommend the Udacity Interactive 3D Graphics course or WebGL 2 Fundamentals for total beginners

This page will act as a table of contents that will be updated as the series progresses.

Not Ninjas, Just Programmers

  var ninja = {
    sneakAround: function() {...},
    strikeFromShadows: function() {...},
    writeStableWebApp: function() {...}
  }; 

Terms like JavaScript ninja or JavaScript wizard tend to make me uneasy. They suggest a set of priorities in programming that I would argue are counterproductive. To begin discussing why, let’s refer to some definitions:

  • ninja [nin-juh], noun: a member of a feudal Japanese society of mercenary agents, highly trained in martial arts and stealth (ninjutsu) who were hired for covert purposes ranging from espionage to sabotage and assassination.
  • wizard [wiz-erd], noun: a person who practices magic; magician or sorcerer.

I wouldn’t consider any of the qualities implied here as important, or even attractive, in software development. Why would anyone want code to be stealthy? Or covert? Or magic? Glorifying these qualities betrays an attitude that shifts focus away from the software we build to the cleverness of the code that’s used to build it. Exploiting syntactic idiosyncrasies in novel ways or displaying one’s knowledge of the esoteric details of a language takes priority over creating robust, maintainable applications. It’s programming as performance, rather than programming as craft.

Continue reading Not Ninjas, Just Programmers

From Web to WebGL: A Guide for Web Developers Entering the Third Dimension

WebGL is an interesting technology in that its community has brought together developers from highly disparate backgrounds. On the one hand, there are 3D graphics programmers who know the GPU architecture, the math, the algorithms, and who previously wrote their software in close-to-the-metal languages like C or C++, generally with OpenGL or D3D as the graphics API. For them, the path to WebGL involves learning the idiosyncrasies and limitations of JavaScript, as well as the best practices of working with the Web as a platform. On the other hand, there are those, like me, with a background in web development who want to use WebGL to build their sites or web applications. I should be clear here that I’m not referring to web developers who just want to get a bit of 3D into their web sites, as can be done with the myriad libraries and frameworks currently available. Rather, I’m referring to those who want to understand and use WebGL at a deep level. This, I would argue, is a far more difficult path than that taken by the graphics programmers and involves developing an understanding of the following three major areas involved in WebGL programming:

  • The WebGL API: The programming model and how it models the GPU
  • 3D Mathematics: Primarily linear algebra and 3D geometry
  • 3D Algorithms: The various techniques used to produce images and optimize their rendering

Continue reading From Web to WebGL: A Guide for Web Developers Entering the Third Dimension

Constructors Are Bad For JavaScript

JavaScript is a language that has always been at odds with itself. It derives its core strength from a simple, flexible object model that allows code reuse through direct object-to-object prototypal inheritance, and a powerful execution model based on functions that are simply executable objects. Unfortunately, there are many aspects of the language that obscure this powerful core. It is well-known that JavaScript originally wanted to look like other popular languages built on fundamentally different philosophies, and this trend in its history has lead to constructs in the language that actively work against its natural flow.

Continue reading Constructors Are Bad For JavaScript

Intimate Distance: The Photography of Thien V

Originally posted at howlarts.net.

panda (520x347)

“I’m in the business of translating what cannot be translated: being and its silence.” – Charles Simic

The Student Strike inspired an effervescence of creative works and artistic expression. The ubiquitous nature of the music, the posters, the interventions, the literature suggests that the arts played a central role in galvanizing the movement. But what exactly is the relationship between art and the politics of the moment? It’s easy to say that art is important to politics or to society in general, but how often do we actually explore what that means? Is the role of art to offer abstracted symbols of the movement, such as the carré rouge or the casseroles, around which to rally? Or is its role rhetorical, to convince its audience of the validity of a particular position? Although these two artistic modalities are important parts of a social movement, I believe the role art has to play can potentially be much deeper. Alain Badiou has written that “Art is pedagogical because it produces truths and because education (save in its oppressive or perverted expressions) has never meant anything but this: to arrange the forms of knowledge in such a way that some truth may come to pierce a hole in them.” By this understanding, art is a naturally destabilising force, puncturing the status quo and established modes of thought, and allowing us to see the potential on the other side. And it is through this action, I believe, that art is inherently political, and that it is political in a way that only art can be.

Continue reading Intimate Distance: The Photography of Thien V