Initial setup:-

Struct for holding vertex data and some #define’s for accessing it

// Location/Normals
#define X_POS 0
#define Y_POS 1
#define Z_POS 2
// Texture Coordinates
#define U_POS 0
#define V_POS 1
// Colours
#define R_POS 0
#define G_POS 1
#define B_POS 2
#define A_POS 3
 
typedef struct
{
	GLFloat location[3];
	GLFloat tex[2];
	GLFloat normal[3];
	GLFloat colour[4];
	GLubyte padding[16]; // Pads the struct out to 64 bytes for performance increase
} Vertex;

So now basically we need to have a place to store all of this data. Now while it would be nice to only store 8 verticies (one for each corner of the cube), we are unable to due to the normals pointing in different directions per face. The best way to remember this is a vertex is a combination of position, normal, texture coordinate and colour, as soon as one of these is different, it’s a different vertex. A cube is an extreme example, in most models, we would be able to share verticies (this is important for the next step).

Vertex verts[24]; // We're making a cube, 6 faces * 4 verticies per face

Now we need to have a place store each index to a face. Basically what this is, is an array that defines each triangle. I’ll go into this more later

GLubyte index[36]; // 2 Triangles per face (possible to use quads, but they're being phased out of OpenGL3, so we're using triangles instead)

So now we initialise our vertex array and index array (only showing 1 face in here to save space, the rest are up left as an exercise to the reader)

void buildCube()
{
	verts[0].location[X_POS] = -1; verts[0].location[Y_POS] = -1; verts[0].location[Z_POS] = 1;
	verts[0].normal[X_POS] = 0; verts[0].normal[Y_POS] = 0; verts[0].normal[Z_POS] = 1;
	verts[0].tex[U_POS] = 0; verts[0].tex[V_POS] = 0; 
	verts[1].location[X_POS] = -1; verts[1].location[Y_POS] = 1;  verts[1].location[Z_POS] = 1;
	verts[1].normal[X_POS] = 0; verts[1].normal[Y_POS] = 0; verts[1].normal[Z_POS] = 1;
	verts[1].tex[U_POS] = 0; verts[1].tex[V_POS] = 1; 
	verts[2].location[X_POS] = 1;  verts[2].location[Y_POS] = 1;  verts[2].location[Z_POS] = 1;
	verts[2].normal[X_POS] = 0; verts[2].normal[Y_POS] = 0; verts[2].normal[Z_POS] = 1;
	verts[2].tex[U_POS] = 1; verts[2].tex[V_POS] = 1; 
	verts[3].location[X_POS] = 1;  verts[3].location[Y_POS] = -1; verts[3].location[Z_POS] = 1;
	verts[3].normal[X_POS] = 0; verts[3].normal[Y_POS] = 0; verts[3].normal[Z_POS] = 1;
	verts[0].tex[U_POS] = 1; verts[0].tex[V_POS] = 0; 
 
	// ********* SNIP (I'll let you fill in the rest of the cube here) *********
 
	// Colors
	for (int i = 0; i < 24; i++)
	{
		verts[i].colour[R_POS] = 1.0;
		verts[i].colour[G_POS] = 1.0;
		verts[i].colour[B_POS] = 1.0;
		verts[i].colour[A_POS] = 1.0;
	}
 
	// Index Array (define our triangles)
	// A Face looks like (numbers are the array index number of the vertex)
	// 1      2
	// +------+
	// |      |
	// |      |
	// +------+
	// 0      3
	index[0] = 0; index[1] = 1; index[2] = 2;
	index[3] = 2; index[4] = 3; index[5] = 0; // Repeated number 2 & 0 as they're shared
	// ********* SNIP (I'll let you fill in the rest of the cube here) *********
}

So as you can see above, in the index array, we’ve defined 2 triangles. (0, 1, 2) and (2, 3, 0). The diagram in the comments show the vertex indicies that map into our vertex array. So from that, you should be able to visualise the triangles in your head. As we’re drawing triangles directly (not triangle strips/fans or quads), we have to repeat some of the index numbers. This is a good thing as it means that we have some shared verticies, and have to upload less data to the graphics card.

So now we start the actual OpenGL code. Firstly we set up the vertex buffer. There are two buffers that get uploaded to the graphics card. One contains the verticies, and the other is the index array. This only needs to be done once (even if the model changes, I’ll explain how to change individual vertices at the end).

// A helper macro to get a position
#define BUFFER_OFFSET(i) ((char *)NULL + (i))
 
GLuint vboID; // Vertex Buffer, this needs to be accessable wherever we draw from, so in C++, this would be a class member, in regular C, it would probably be a global variable;
 
glGenBuffers(1, &vboID); // Create the buffer ID, this is basically the same as generating texture ID's
glBindBuffer(GL_ARRAY_BUFFER, vboID); // Bind the buffer (vertex array data)
 
// Allocate space.  We could pass the mesh in here (where the NULL is), but it's actually faster to do it as a 
// seperate step.  We also define it as GL_STATIC_DRAW which means we set the data once, and never 
// update it.  This is not a strict rule code wise, but gives hints to the driver as to where to store the data
glBufferData(GL_ARRAY_BUFFER, sizeof(Vertex) * 24, NULL, GL_STATIC_DRAW);
glBufferSubData(GL_ARRAY_BUFFER, 0, sizeof(Vertex) * 24, verts); // Actually upload the data
 
// Set the pointers to our data.  Except for the normal value (which always has a size of 3), we must pass 
// the size of the individual component.  ie. A vertex has 3 points (x, y, z), texture coordinates have 2 (u, v) etc.
// Basically the arguments are (ignore the first one for the normal pointer), Size (many components to 
// read), Type (what data type is it), Stride (how far to move forward - in bytes - per vertex) and Offset 
// (where in the buffer to start reading the data - in bytes)
 
// Make sure you put glVertexPointer at the end as there is a lot of work that goes on behind the scenes
// with it, and if it's set at the start, it has to do all that work for each gl*Pointer call, rather than once at
// the end.
glTexCoordPointer(2, GL_FLOAT, sizeof(Vertex), BUFFER_OFFSET(12));
glNormalPointer(GL_FLOAT, sizeof(Vertex), BUFFER_OFFSET(20));
glColorPointer(4, GL_FLOAT, sizeof(Vertex), BUFFER_OFFSET(32));
glVertexPointer(3, GL_FLOAT, sizeof(Vertex), BUFFER_OFFSET(0));
 
// When we get here, all the vertex data is effectively on the card
 
// Our Index Buffer, same as above, the variable needs to be accessible wherever we draw
GLuint indexVBOID;
glGenBuffers(1, &indexVBOID); // Generate buffer
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, indexVBOID); // Bind the element array buffer
// Upload the index array, this can be done the same way as above (with NULL as the data, then a 
// glBufferSubData call, but doing it all at once for convenience)
glBufferData(GL_ELEMENT_ARRAY_BUFFER, 36 * sizeof(GLubyte), index, GL_STATIC_DRAW);

And that’s all there is to getting the data onto the card itself. The only gotcha is to put the glVertexPointer last when you’re setting up your pointers.

Now to paint the code. This will need to go in your render loop after you’ve done your camera transformations

// Bind our buffers much like we would for texturing
glBindBuffer(GL_ARRAY_BUFFER, vboID);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, indexVBOID);
 
// Set the state of what we are drawing (I don't think order matters here, but I like to do it in the same 
// order I set the pointers
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glEnableClientState(GL_COLOR_ARRAY);
glEnableClientState(GL_NORMAL_ARRAY);
glEnableClientState(GL_VERTEX_ARRAY);
 
// Resetup our pointers.  This doesn't reinitialise any data, only how we walk through it
glTexCoordPointer(2, GL_FLOAT, sizeof(Vertex), BUFFER_OFFSET(12));
glNormalPointer(GL_FLOAT, sizeof(Vertex), BUFFER_OFFSET(20));
glColorPointer(4, GL_FLOAT, sizeof(Vertex), BUFFER_OFFSET(32));
glVertexPointer(3, GL_FLOAT, sizeof(Vertex), BUFFER_OFFSET(0));
 
// Actually do our drawing, parameters are Primative (Triangles, Quads, Triangle Fans etc), Elements to 
// draw, Type of each element, Start Offset
glDrawElements(GL_TRIANGLES, 36, GL_UNSIGNED_BYTE, BUFFER_OFFSET(0));
 
// Disable our client state back to normal drawing
glDisableClientState(GL_TEXTURE_COORD_ARRAY);
glDisableClientState(GL_COLOR_ARRAY);
glDisableClientState(GL_NORMAL_ARRAY);
glDisableClientState(GL_VERTEX_ARRAY);

And that’s all there is to drawing (and VBO’s pretty much). An interesting side note. Before VBO’s, it was more efficient to use GL_TRIANGLE_FAN and GL_TRIANGLE_STRIP for drawing, but now it’s much better to just use GL_TRAINGLES due to the way the card does caching. Using strips and fans can actually cause cache misses which is much worse on modern cards than having to reference more verticies.

If you want to dynamically update your mesh per frame, that’s quite easy too, although be warned, there is quite a performance hit by doing it (although, not as bad as recreating a display list). All you need to do is rather than using GL_STATIC_DRAW, use GL_STREAM_DRAW (if it’s changing per frame), or GL_DYNAMIC_DRAW (if it changes a bit, but not per frame). Then you can use glBufferSubData (shown where we set up the VBO initially) on either your vertex data or your index data to update a single value (or range of values).

VBO Example Code (requires GLUT)

As for my stuff, screenshot below, is reflecting a nice cubemap, mixed in with some colour, a dynamically moving light (doing per pixel lighting), all at a nice 40FPS (which makes this picture around 9 million triangles per second).

I’ve been working on a new OpenGL program. Didn’t finish the last one as I decided I wanted to make a portable application (ie, so I can port it to Windows, and possibly even DirectX one day). Only a touch of Objective-C/Cocoa to set up the windowing and use some nice OS specific functions (such as Cocoa automatically being able to decode PNG files), most of it is written in C++

So I’ve been playing around with VBO’s (Vertex Buffer Objects) and FBO’s (Frame Buffer Objects) which I had been doing in the previous program, but it turns out I was doing it slightly wrong. So now that it’s all working correctly I have a bit of an app going.

Currently it pretty much only loads Obj models (a simple ASCII based format), but most 3D applications will export this.

Underneath there is a lot going on. It has:-

• Obj Model loading/rendering code
  • Works in both VBO mode and Immediate mode for debugging purposes
• Quake style console (not shown)
  • Press ~ to bring it down, and you can type commands, register/change variables (currently moving the camera around is done like this, as is model loading)
• Texture manager
  • I can keep track and list all the used textures
• Shader manager
  • Like the texture manager, to keep track of it all
• Font manager
  • Rendering fonts/strings to the screen
  • Using a single font texture “atlas” for all the characters, basically one big texture that slides its position around on a triangle fan (or quad if you prefer to think of it that way) to only show the correct character entirely done in GLSL (GL Shader Language – basically programming directly on the graphics card)
• Particle renderer (not shown)

Next things I’d like to do are is have a model manager to allocate one (or more) large VBO on the card to hold lots of smaller models and index them within the VBO, more shaders – I’d really love to try some SSAO (Screen Space Ambient Occlusion – basically simulating the way that indirect light will still light and shadow things) and deferred lighting/shadowing and write a full GUI for it for things like menus, combo boxes, buttons, etc.

I’m sure I’ll come up with a lot more, possibly turning it into some type of game engine one day.

Here’s a screenshot of what I have so far.

It doesn’t look like much, but there’s a lot of work going on there.

The colours you can see on the model (which I actually made myself) are what’s known as a normal map. It’s the way lighting is calculated on 3D models.

Unfortunately there’s a couple of problems with this model.

1. The first one that stands out is that it’s missing parts. When I exported the model, I accidentally left some of the parts as Sub-D and NURBS surfaces, which can’t be directly rendered by my renderer (or even represented in the Obj file). I’ve actually exported what I think is a proper model, just haven’t copied the file onto my laptop yet.
2. The other one that isn’t so obvious unless you know what you’re looking at. With normal maps, we represent the normal as a colour. Basically Red = X, Green = Y and Blue = Z. Now a triangle (which is what the model is made up of) that is facing the camera should typically have a blueish tinge (like the bottom of the car does), but as you can see, the door is a green/orange colour. What is happening is that many of the triangle are actually facing the wrong way. Oops. Will have to fix that up

One thing that may stick out in that screenshot too (at least if you click it and view it in full size) is that the frame rate is only 20FPS. Basically there are three reasons for this:-

1. The first one is that I’m only rendering a frame once a millisecond (which works out to be around 40FPS) rather than maxing it out at the fastest possible rate
2. Next it’s only a debug build, so the compiler hasn’t optimised the code
3. Finally the model is 300,000 triangles, so in that alone, we’re doing around about 6,000,000 triangles per second (triangles * fps) , which that said isn’t fantastic (I am on a laptop graphics card though), but due to the way I’m calling the code, it will be a direct division of 40… ie, 40, 20, 10, etc.

So next post, I’ll hopefully show a proper render of the model. Maybe even throw in a quick tutorial on VBO’s (which are really quite easy when you get your head around them).

Ok, so this is what I’ve been working on recently. I know there’s a few of these out there, but I’m more doing this to learn shaders for myself (along with VBO’s – Vertex Buffer Objects – and FBO’s – Frame Buffer Objects) along with Objective-C/Mac programming.

So what you’re seeing there is a slight Gaussian blur on the texture itself and a radial blur on the whole scene itself (using an FBO mapped onto a Quad that fills the screen).

As you can see on the right, it has a built in editor. It will eventually have syntax highlighting, but I had to disable that temporarily as it was causing some issues.

This will let you remotely debug an applet using Eclipse.  As far as I know, this will only work with Java 1.6 update 11 and above, but you can have old VM’s installed and only have them enabled (I’ll leave that as an exercise to the reader).

1. You will need JDK 1.6 update 11 installed (which should install JRE update 11 along with it)
2. Open your Java Control Panel, go to the Java Tab, and click the view button for Java Applet Runtime Settings
   

   Applet Settings Window

3. Click Find and navigate to your JDK directory (in my case it was C:\Program Files (x86)\Java\jdk1.6.0_11\jre)
4. Double click the Version field, add something like -debug to the string and disable the other VM’s
   

   Applet Settings after adding VM

5. Add your normal debug parameters in Java Runtime Parameters (in my case -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,address=1235,suspend=n)
6. Hit Ok/Apply on everything and close the Java Control Panel page
7. In Eclipse make sure your default JDK is the one specified in the applet runtime settings (in your project properties)
8. Open the Debug Configurations (under the Run menu), select your particular Remote Java Application, and go to the Source tab
9. Click Add and select External Archive
10. Select your src.zip in your JDK directory (in my case C:\Program Files (x86)\Java\jdk1.6.0_11\src.zip)
    

    Eclipse Debug Window

11. Press Apply and you should now be able to debug your applet as normal, but with the added bonus of being able to step into the JDK code

So, have a couple of updates for this today. Firstly, I have a very cool girlfriend. For our anniversary (2 wonderful years), she bought me this:-

How awesome! Two of my favourite things, Star Wars, and lots of female flesh

Secondly, I’ve picked myself up a new MacBook Pro

It’s just the base model of the pro’s, but it’s absolutely awesome. Idealy I want to write apps for both the Mac and for the iPhone.

I’m still going through an learning Objective C/Foundation libraries. Getting there slowly. I think the hardest bit for me to get my head around is using the Interface Builder to link my classes to the ui. A very different style to what I’m used to, and not sure if I like it yet or not. I’m all happy with the speedy creation (even if it does feel a bit like cheating), but I’m not a fan of not having actual code behind it for future flexibility. We’ll see how restrictive it is though.