Tutorial: Faster rendering with vertex buffer objects

Hi again! Wade Walker here: engineer, would-be scientist, and second-time tutorializer.

I return as well! Dashing being-about-town and nascent heading-writer “Interstitius”, at your service

What can I say—he brings a unique sensibility to his work. Anyway, in our last tutorial, me and Stish showed how to create the skeleton of a scientific app using Eclipse RCP and Java OpenGL (JOGL, which I like to pronounce “joggle”).

This time, I’ll show how to speed up rendering by using OpenGL’s “vertex buffer objects” instead of glBegin and glEnd like we did last time. I’ll also keep evolving the tutorial towards a “real” scientific app by making the data source more like scientific data.

Science, ho!

Formerly our method of drawing was easy, but slow

This is how you draw one quadrilateral (what we call a “square”, “rectangle”, “trapezoid”, or “rhombus” in English, except that the last two are technically Greek) in old-style OpenGL:

glBegin( GL_QUADS );
    glVertex3f( -1.0f, 1.0f, 0.0f );    // top left
    glVertex3f( 1.0f, 1.0f, 0.0f );     // top right
    glVertex3f( 1.0f,-1.0f, 0.0f );     // bottom right
    glVertex3f( -1.0f,-1.0f, 0.0f );    // bottom left
glEnd();

Perfectly straightforward – it draws one quad, which has four vertices, as quads often do. Easy to understand, easy to write. So why not do everything like this?

In a somewhat predictable inversion, our new method is difficult, but fast

Here’s why we can’t: in a real app, you’ve got a huge mess of stuff between glBegin and glEnd, and the OpenGL driver will struggle to optimize it into something efficient that it can send to the graphics card. Sometimes this works OK, but other times the driver can’t handle it well, and the result is something that’s correct, but slow.

Here’s how we fix it. We create a vertex buffer object, which is just a big chunk of memory that holds the objects we want to draw. Then we send it to our graphics card all at once, where it gets drawn super-fast by dedicated hardware.

The new hotness of vertex buffer objects makes you do all the hard work of setting up your object data in the exact format that the graphics card can process the fastest. So at the price of a few extra drops of programmer brain-juice, your users get faster graphics. And everyone’s happy!

I won’t show an example yet, because it’s too ugly to put first thing in the tutorial. Just hold on to that dream of gloriously fast graphics while we set up this new project.

Importing all of one’s projects at a stroke

This time instead of crawling through the tutorial one file at a time, I zipped up all the projects so you can slurp them into Eclipse all at once.

Download this file and this file, rename them so they end with “.zip” instead of “-zip-not-a.doc”, and unzip them inside an empty folder that you’ll use as a new Eclipse workspace. Then start Eclipse, select “File > Switch Workspace > Other…”, browse to your new workspace folder, and click “OK”. If you see the welcome screen, click the “Workbench” button on the right to go past it.

 Then select “File > Import…” from the main menu, select “Existing Projects into Workspace”, and click “Next”.

Click “Browse…”, navigate to your workspace folder, and click “OK”. Then you should see these seven projects. Click “Finish” to import them into your workspace.

The word “import” is a little misleading here, since the projects were already in your workspace folder. What happened just then was Eclipse wrote into its “.metadata” folder inside the workspace folder, to tell itself which projects are in the workbench. The next time you open Eclipse, you should see the same projects again.

A rather unsporting leap forward to reveal this tutorial’s outcome

Let’s run the tutorial first to see what it does, then I’ll go back and explain it. After importing the projects, you should be seeing this:

Now right-click on “name.wadewalker.vbotutorial” in the “Package Explorer” view on the left, then select “Run As > Eclipse Application.” Now bask in the glory of vertex buffer objects! Yes, bask!

Perhaps a bit of explanation is needed for this rather uninspiring image?

I’m on it. This is supposed to approximate what a scientific visualization program might do. The sine wave on screen is made of 300,000 skinny vertical quads of different colors. The quads are stationary, but they’re constantly changing size to make the sine wave look like it’s moving. The “frames per second” (FPS) counter in the bottom left shows you how fast your system can render this demo. The code that creates this data is in DataSource.java.

Before an actual scientist VR-stabs me over the internet, let me say that of course no scientist would need to visualize something so simple. Because they’re all über-geniuses! But this demo is to show us how to program, not how to drop science. The point is that we have a source of data that’s constantly changing, and we have to throw it up on screen as it evolves.

So how does it work?

Creating a vertex buffer object ex nihilo

Technically it’s not created from nothing, it’s created from electrons, smarty-shorts. To see how, open up the “name.wadewalker.vbotutorial” project in the Package Explorer on the left, then drill down to “src/name.wadewalker.vbotutorial”, double-click on “JOGLView.java”, and scroll to this part.

//================================================================
/**
 * Creates vertex buffer object used to store vertices and colors
 * (if it doesn't exist). Fills the object with the latest
 * vertices and colors from the data store.
 *
 * @param gl2 GL object used to access all GL functions.
 * @return the number of vertices in each of the buffers.
 */
protected int [] createAndFillVertexBuffer( GL2 gl2, List<DataObject> listDataObjects ) {

    int [] aiNumOfVertices = new int [] {listDataObjects.size() * 4};
        
    // create vertex buffer object if needed
    if( aiVertexBufferIndices[0] == -1 ) {
        // check for VBO support
        if(    !gl2.isFunctionAvailable( "glGenBuffers" )
            || !gl2.isFunctionAvailable( "glBindBuffer" )
            || !gl2.isFunctionAvailable( "glBufferData" )
            || !gl2.isFunctionAvailable( "glDeleteBuffers" ) ) {
            Activator.openError( "Error", "Vertex buffer objects not supported." );
        }

        gl2.glGenBuffers( 1, aiVertexBufferIndices, 0 );

        // create vertex buffer data store without initial copy
        gl2.glBindBuffer( GL.GL_ARRAY_BUFFER, aiVertexBufferIndices[0] );
        gl2.glBufferData( GL.GL_ARRAY_BUFFER,
                          aiNumOfVertices[0] * 3 * Buffers.SIZEOF_FLOAT * 2,
                          null,
                          GL2.GL_DYNAMIC_DRAW );
    }

    // map the buffer and write vertex and color data directly into it
    gl2.glBindBuffer( GL.GL_ARRAY_BUFFER, aiVertexBufferIndices[0] );
    ByteBuffer bytebuffer = gl2.glMapBuffer( GL.GL_ARRAY_BUFFER, GL2.GL_WRITE_ONLY );
    FloatBuffer floatbuffer = bytebuffer.order( ByteOrder.nativeOrder() ).asFloatBuffer();

    for( DataObject dataobject : listDataObjects )
        storeVerticesAndColors( floatbuffer, dataobject );

    gl2.glUnmapBuffer( GL.GL_ARRAY_BUFFER );

    return( aiNumOfVertices );
}

First we create a vertex buffer object with glGenBuffers, then do a glBufferData to allocate the size we want. Every vertex needs three floats for the position (x, y, z), and three more for the color (r, g, b). Then we use glMapBuffer to get an object we can write into, we write all our floats into it, then we call glUnmapBuffer to finish.

Might you explain why both colors and vertices are placed into a so-called “vertex buffer”?

Aha, good point! It’s true that in math, a “vertex” is really just a point where lines meet, but in computer graphics we can also consider the color to be a part of the vertex. There can be more stuff in a vertex too, like the normal vector, texture coordinates, and other things we don’t need yet. So “vertex buffer” isn’t really a misnomer.

Why, then, do we interdigitate the positions and colors? Could we not write all of one, then all of the other?

Alternating positions and colors in a single vertex buffer speeds things up by preserving data locality. When you write the data into the buffer, you don’t want to be writing to two widely separated addresses, because your computer’s memory system isn’t good at that.

Similarly, if the graphics card has to fetch the positions from one address in memory and the colors from a very different address to render each triangle, it’s gonna be slower than if all the data for that triangle is close together.

I originally used separate position and color buffers for this tutorial, and when I switched to one “interdigitated” buffer, I got a 5% to 10% increase in frame rate.

Rendering one’s vertex buffer

Here’s the code to draw the vertex buffer we just created, also in JOGLView.java:

// needed so material for quads will be set from color map
gl2.glColorMaterial( GL.GL_FRONT_AND_BACK, GL2.GL_AMBIENT_AND_DIFFUSE );
gl2.glEnable( GL2.GL_COLOR_MATERIAL );

// draw all quads in vertex buffer
gl2.glBindBuffer( GL.GL_ARRAY_BUFFER, aiVertexBufferIndices[0] );
gl2.glEnableClientState( GL2.GL_VERTEX_ARRAY );
gl2.glEnableClientState( GL2.GL_COLOR_ARRAY );
gl2.glVertexPointer( 3, GL.GL_FLOAT, 6 * Buffers.SIZEOF_FLOAT, 0 );
gl2.glColorPointer( 3, GL.GL_FLOAT, 6 * Buffers.SIZEOF_FLOAT, 3 * Buffers.SIZEOF_FLOAT );
gl2.glPolygonMode( GL.GL_FRONT, GL2.GL_FILL );
gl2.glDrawArrays( GL2.GL_QUADS, 0, aiNumOfVertices[0] );

// disable arrays once we're done
gl2.glBindBuffer( GL.GL_ARRAY_BUFFER, 0 );
gl2.glDisableClientState( GL2.GL_VERTEX_ARRAY );
gl2.glDisableClientState( GL2.GL_COLOR_ARRAY );
gl2.glDisable( GL2.GL_COLOR_MATERIAL );

glcanvas.swapBuffers();

We use glVertexPointer and glColorPointer to set the starting positions in the buffer, with the first color pointer three floats after the first position. Then we tell the graphics card that each new position and color is six floats past the current one. We call that a “stride” of six floats, which is 24 bytes. Then finally we draw the whole buffer full of quads with just one command, glDrawArrays.

What, then, is the benefit of all our labors?

I did this tutorial with glBegin/glEnd first, as a test. When I switched to a vertex buffer, the frame rate increased by 100%.

And this is a worst-case scenario, too. In many apps, most of the scene will be constant from one frame to the next, so we can just move the viewpoint and call glDrawArrays again without changing the vertex buffer at all.

As a test, I changed the tutorial code to only write the vertex buffer once, and the frame rate jumped from 14 to 25. So vertex buffers are almost 200% faster than glBegin/glEnd for this more common situation.

Might we run faster still?

There are 600K triangles here (2 per quad), and at 14 FPS, that’s 8.4 million triangles per second. With the vertex buffer written only once, we get 25 FPS, or 15M tris/sec.

I downloaded the NVIDIA performance tools and profiled a couple of C++ DirectX demos that come with them. One got 5.7M tris/sec, and one got 8.4M tris/sec. They had texturing and other effects turned on, so their rendering isn’t as simple as ours, but their triangle rates seem comparable.

But! When I look at the theoretical maximum speed, things aren’t so clear. My graphics card is an NVIDIA GeForce 8800 GTX, which can supposedly do 250M tris/sec on the 3DMark06 benchmark. That would give 417 FPS on our tutorial! Why is 3DMark06 16 times faster than us?

A few thought-experiments as to how our speed could be increased

Part of it may be the geometrical primitives 3DMark06 is rendering. We’re rendering quads, which have four vertices for two triangles, which means two vertices per triangle. If we jumped ahead in the OpenGL playbook and used triangle strips instead, we could get that down to one vertex per triangle, which could double our frame rate.

But we need to double our rate three more times to get to that theoretical max. If we removed the color information and just drew all the triangles in the same color, we could halve the size of our vertices and maybe double the speed again.

But how do we double it two more times? No clue.

Maybe changing the vertex buffer every frame is saturating the bus between my computer and the video card? Let’s check.

My video card is designed for an x16 PCI Express 1.x slot, which is rated at 4GB/sec. In this tutorial, each vertex buffer is (300,000 quads) * (4 verts/quad) * (6 floats/vert) * (4 bytes/float) = 28,800,000 bytes. At 14 FPS, that’s 403,000,000 bytes/sec, which is only about 10% of our bus capacity. So that can’t be the problem.

Hmm, I’m out of ideas for the moment. But handing back my super-genius credentials isn’t an option, so I’ll look into this and cover it in a future tutorial.

Resources which the reader may find helpful

OpenGL tutorials: Check out http://nehe.gamedev.net/. These go over OpenGL more slowly and thoroughly than I do, and are recommended.

The OpenGL Programming Guide, n^th edition: You can buy it for about $50 on Amazon. It’s definitive, but not exactly a tutorial. The style of OpenGL I’ve used so far is actually 1.5 to 2.0, not the latest 4.1 stuff, so make sure to get a book about the version you want.

Basic documentation: At http://www.opengl.org/ you can find docs for the C API calls. The ones in JOGL are Java-fied, but you can usually tell how to translate one to the other.

A list of the revisions which we have made to this document

10/17/2010: Wrote first version.

10/23/2010: Updated to split the zip file and include JOGL for multiple platforms.

10/26/2010: Fixed the links to full-sized images.