A large part of the training actually involves teaching newcomers how to code. This is actually the main focus of the training as they hire people who have majored in math or economics and don’t have a background in code. Having quite a large background in code, the training has been rather dull. But it’s still good for me to know how the company works, and it has made me comfortable enough that I won’t have the pressure of a new job bearing down on me once I actually start doing important work.

But my background also gives me a different perspective on coding and the specifics of languages that I’ve used. When they are told things about a language, they just have to accept it and move on without really questioning the reasons. For instance: they were taught that the difference between & and && in Java has to do with what exactly is executed when used in an if statement.

So, the following two if statements are executed differently. The first will not execute obj.hasElements() when obj is null, while the second statement will throw a NullPointerException.

if(obj != null && obj.hasElements()) {
    obj.run();
}

if(obj != null & obj.hasElements()) {
    obj.run();
}

Of course, this is correct; however, I have a problem with explaining the difference between the two AND statements for a couple reasons. Firstly, BitwiseAND and BitwiseOR are my namesake websites, and really are close to my heart. When described so poorly, I feel a need to speak out on their behalf. Secondly, the second if statement really wouldn’t be used this way; at least not in Java (I could see this occurring in C++ quite a bit). Bitwise operators (&, |, ^, …) are for manipulating bits, not booleans (as the name implies). Likewise, logical operators (&&, |, !, …) are for logic statements. There is no reason to write the second if statement for efficiency and semantic reasons.

Now, to be fair, the instructors must have mentioned this to let the students know why a program was crashing with the second version and why they should stick to the first version. I asked one of the students if they gave any scenario in which the bitwise operations would be used, and I was told that they didn’t give any examples.

So, the students are seeing the bitwise operations and are left with a sense that they should never use them in an if statement and therefore are pointless additions to the Java language. Never to be used and only to confuse you when you use & instead of &&.

Not planning to code, not testing by hand, but pure coding from scratch and then untangling the mess I made by debugging it. That’s why I don’t care for certain methodologies. The Waterfall method specifically.

Don’t get me wrong; when done correctly coding models work beautifully. In fact, it was the Waterfall model that I just used recently on a small program that worked so well to show me how much I despise.

First, we start with the requirements. Make a list of the major requirements in the project, now break those down into manageable pieces, break those down into finer details, keep breaking down each item in the list until you have one specific requirement for each bullet point. Now your list is 30 pages long and 15 levels deep.

Now that we have a list of requirements, “design” your program. Don’t code it; “design” it in psuedocode.

Next, create your test data. Make sure you have a test for each and every requirement. Also make sure that each branch in you design is tested somehow. Be thorough; test edge conditions, test invalid input. Verify that every possible input is going to be tested. Now test your design by hand. I know this sounds like something a computer can do better than a human, and in fact, it is. However, you would have to code your design in order to test it and that part comes later.

After killing yourself by pouring over each line of code with every item of test data you are now ready to code your program. Lucky for you, you’ve managed to create a perfect design after all that testing by hand, so this is actually the easy part. No thinking involved other than dealing with the minutia of the language itself (but you probably hinted at that in the design anyway).

Now do your actual testing in order catch your coding mistakes. Run all the test data through and compare it with the output from earlier. It all works great right? Great!

You’ve just managed to do so much work in advanced that the actual coding and debugging has become the shortest part of the process. The rest of the time you spent doing boring tasks that put you to sleep.

Now, not all methodologies are like this. Variants of the Agile method are more oriented towards the needs of the programmer instead of the needs of a corporation. These other methods make the time line of a project seem uncertain and risky, but in my experience, the final project has a higher quality and you’ve made your programmers happier at the same time by working with them instead of demanding deliverables.

So, long story short, the Waterfall method is a great way to make a working program, as long you think coding and debugging is the most expensive or least important part of the process. I, on the other hand, love to code. Requirements and designs are necessary, sure, but not in such detail. Lets get to the coding and test from there. Don’t make me do so much work that I will only do poorly because I hate it so; just tell me what you want, and I’ll code it for you.

The first thing we do is understand the layout of the maps. Really, we’ll only be rendering to a single texture. This has the advantage of saving space, but may cause a problem if we only have 8 bits per channel. If the normal {x, y, z} is stored in {r, g, b} and the depth stored in {a}, then we’ve gone from 32 bit floating point {x} to 8 bit {r}, or 24 bit depth to 8 bit {a}; the same goes for the other components. This loss in precision will show up in banding artifacts and the errors will be carried through for every computation that follows that map use. But sometimes this is unavoidable based on the platform that we’re using.

How do we fit a normal and depth into a single pixel? Well, we know which color component will hold which value, but we then find out that the GL will clamp our texture values to [0,1]. No negative values for us. Luckily, the depth is already clamped to [0,1] by virtue of the graphics pipeline; the normal is an entirely different problem. It does have an easy solution though. Normals can be normalized (duh), which means each component will map to [-1,1]. If we normalize, then multiply by two and subtract one, our mapping will be fine. We just need to undo the tranformation when we reference it later on.

This gives us our GLSL vertex shader:

varying vec3 normal;
varying float depth;
void main()
{
gl_Position = ftransform();
normal = gl_NormalMatrix * gl_Normal;

vec4 eyeTmp = gl_Position;
eyeTmp.xyz = eyeTmp.xyz / eyeTmp.w;
depth = eyeTmp.z;
}

And our fragment shader:

varying vec3 normal;
varying float depth;

gl_FragColor = vec4(N, depth);
}

Now, that may not be the absolute best way, but it works on nearly every platform that can use GLSL. One issue that I should bring up, is that the pixel’s depth value can be directly referenced in the fragment shader through gl_FragCoord.z; on some machines, reding this value was very, very slow, but now I’ve seen great improvement in reading the value. This means we can remove all references to the varying variable depth from both shaders.

Depending on your system, you may have acces to floating point textures through GL_ARB_texture_float. Two very nice things about that extension. First, floating point textures are not clamped by the GL. This means that messing around with the normals can be avoided. Second, we are no longer limited to 8 bits per channel. We now have access to 16 or 32 bits per channel which will reduce or remove banding issues completly.

Now what do our shaders look like? The vertex shader:

varying vec3 normal

void main(void) {
gl_Position = ftransform();
normal = gl_NormalMatrix * gl_Normal;
}

Fragment shader:

varying vec3 normal;

void main (void) {
gl_FragColor = vec4(normalize(normal), gl_FragCoord.z);
}

Object Space to Image Space (Quick and Dirty)

First, how do we move from object space to image space in OpenGL? Well, we start off with a vertex V in object space, simple enough. Then, some transforms are applied to the object. Let’s say it gets rotated, translated, scaled, rotated again and translated once more. Each of these transforms can be described by their own matrix, but for simplicity’s sake, we’ll say that they were all multiplied into a single matrix – M. So, we have V, a vertex in object space, and now V * M, a vertex in world space.

Next, there’s the transformation from world space to camera space. In OpenGL, camera space consists of right = +X, up = +Y, and forward = -Z. This can be done using the command gluLookAt with the camera’s location, point of focus and up vector. We’ll call this matrix C. Moving a vertex from object space to camera space is then V * M * C, seeing the pattern?

Once we are in camera space, we use the projection matrix (specified with functions like glFrustum and gluOrtho2D) to again change the coordinate space. We’ll call this matrix P, and the sequence V * M * C * P will tell us which vertexes will be clipped. Once in this space (and after the perspective divide), if x or y coordinates of the vertex are outside [-1,+1] or if the z coordinate is outside [0, +1], then the vertex is clipped.

So, what do we have? Taking a vertex V in object space, multiplying it by M moves it to world space, multiplying that by C moves it to camera space, multiplying it P moves it to projected space. V * M * C * P.

Model View Matrix: Object Space to Camera Space

The matrix created to move a vertex to world space is defined by the various transforms applied to that vertex in OpenGL through functions like glTranslate, glRotate and glScale. Loading on the transforms creates a single matrix to change to world space. It’s also worth noting that the final matrix has an inverse and it is very easy to create if you know the tranforms that were used to create it. Let’s say you translate something by 10, rotate it by 90 and scale it by 0.5. This results in a 4×4 matrix where the original transforms have been muddled together to do the entire series of transforms at once. The inverse of this matrix would have to undo each of those transforms in the proper order. So the inverse can be constructed by scaling by 2.0, rotating by -90 and translating by -10. Easy as pie.

The camera space transform can be easily specified by the function gluLookAt. That link contains the implementation to create the matrix for OpenGL. Here’s a sampler to see implementation using GLSL like C++ types.

mat4 makeGluLookAt(vec3 eye, vec3 center, vec3 up)
{
	// forward pointing vector
	vec3 f(center - eye);
	f.normalize();
	up.normalize();

	// right pointing vector
	vec3 s(f.cross(up));

	// orthonormal up vector
	vec3 u(s.cross(f));

	s.normalize();
	u.normalize();

	// construct orthonormal orientation transfom
	mat4 Orient(
		s.x, s.y, s.z, 0.0f,
		u.x, u.y, u.z, 0.0f,
		-f.z, -f.y, -f.z, 0.0f,
		0.0f, 0.0f, 0.0f, 1.0f
	);

	// translate the new coordinate system to the origin
	mat4 Translate(
		1.0f, 0.0f, 0.0f, -eye.x,
		0.0f, 1.0f, 0.0f, -eye.y,
		0.0f, 0.0f, 1.0f, -eye.z,
		0.0f, 0.0f, 0.0f, 1.0f
	);

	return Orient * Translate;
}

If you pay close attention to the Orient matrix, you’ll see that the rows represent the right, up and -forward that will correspond to +X, +Y and +Z (remember that the OpenGL camera looks down -Z). This is a standard change of orientation matrix; this will effectively rotate the world around so that the +X, +Y, and +Z axis line up with the right, up and -forward vectors of the camera. We then translate by the position of the camera to move the old origin to the camera’s origin.

One sticky part to note about all of this is that we have been working with row-wise matrices that are intended to be post multiplied. That is, we start with the vertex, then multiply by the transforms, then multiply by the camera matrix. But, OpenGL uses pre-multiplied matrices to achieve the same effect (that’s why you clear the model view matrix, then specify the camera, then specify the transforms and finally the vertex last). In order to end up with the same matrices in the end, OpenGL needs to use transposed matrices, or column-wise matrices. This means that our function needs to be reworked. One important point to remember: the transpose of multiplied matrices is the same as multiplying the transpose of the matrices in reverse order, ie. (A * B)T = BT * AT. Here is the correct OpenGL Friendly code.

mat4 makeGluLookAt(vec3 eye, vec3 center, vec3 up)
{
	vec3 f(center - eye);
	f.normalize();
	up.normalize();

	vec3 s(f.cross(up));
	vec3 u(s.cross(f));

	s.normalize();
	u.normalize();

	mat4 Orient(
		s.x, u.x, -f.x, 0.0f,
		s.y, u.y, -f.y, 0.0f,
		s.z, u.z, -f.z, 0.0f,
		0.0f, 0.0f, 0.0f, 1.0f
	);

	mat4 Translate(
		1.0f, 0.0f, 0.0f, 0.0f,
		0.0f, 1.0f, 0.0f, 0.0f,
		0.0f, 0.0f, 1.0f, 0.0f,
		-eye.x, -eye.y, -eye.z, 1.0f
	);

	return Translate * Orient;
}

It is important to realize that OpenGL’s Model View matrix is actually M * C, so, if we want to get the position of the vertex in world space, we will have to use the modelview matrix to go to camera space, then multiply by C-1 (the inverse of the camera matrix). This gives us V * M * C * C-1 = V * gl_ModelViewMatrix * C-1 = V * M. And world space is exactly what we need to do shadow mapping, refraction, reflection and a plethora of other things. OpenGL took care of this for us with the GL_ARB_Shadow extension. By using glTexGen, OpenGL computes the inverse camera matrix and applies it without us having to fuss with inverses. But, now we’ll need to do an inverse ourselves.

Inverse gluLookAt

Remember that the camera matrix is given to us by gluLookAt, and above, we have the exact implementation of how the matrix is created. If you know your matrices, you may notice some properties that the camera matrix adheres to when being constructed this way. Normally, for a generic matrix, the inverse is a slow and painful process. You really don’t want to invert a lot of matrices in order to run your program in real time. Luckily, the camera matrix isn’t just a generic matrix, it has a specific construction with easily invertable properties.

If you paid attention to the construction of the Orient matrix, you would have seen that the columns represent an orthonormal coordinate system. That is, the vectors, s, u and -f are all at 90 degree angles to each other and their lengths are equal to 1. The property that this gives us is that the dot product of any two of those vectors equal 0 when the vectors are different. When the vectors are the same, the dot product is the length of the vector squared, or 1.

Now, imagine a matrix multiply as the dot product of two vectors, the row of the first matrix and the column of the second matrix. What we want to do is construct the inverse of Orient such that Orient * Orient-1 equals the identity matrix (0’s everywhere with 1’s on the diagonals), see where I’m going? As it turns out, the inverse of a matrix that represents an orthonormal coordinate system is exactly it’s transpose.

mat4 Orient(
	s.x, u.x, -f.x, 0.0f,
	s.y, u.y, -f.y, 0.0f,
	s.z, u.z, -f.z, 0.0f,
	0.0f, 0.0f, 0.0f, 1.0f
);

mat4 OrientInverse(
	s.x, s.y, s.z, 0.0f,
	u.x, u.y, u.z, 0.0f,
	-f.x, -f.y, -f.z, 0.0f,
	0.0f, 0.0f, 0.0f, 1.0f
);

But the camera matrix also contains a translation that gets multiplied to Orient. We know the inverse of a translation is just a negative translation, so that’s easy. So, if C = Translate * Orient, then C-1 = (Translate * Orient)-1 = Orient-1 * Translate-1. Hey, we know all those pieces! Let’s put it into OpenGL friendly code.

mat4 makeGluLookAtInverse(vec3 eye, vec3 center, vec3 up)
{
	vec3 f(center - eye);
	f.normalize();
	up.normalize();

	vec3 s(f.cross(up));
	vec3 u(s.cross(f));

	s.normalize();
	u.normalize();

	mat4 OrientInverse(
		s.x, s.y, s.z, 0.0f,
		u.x, u.y, u.z, 0.0f,
		-f.x, -f.y, -f.z, 0.0f,
		0.0f, 0.0f, 0.0f, 1.0f
	);

	mat4 TranslateInverse(
		1.0f, 0.0f, 0.0f, 0.0f,
		0.0f, 1.0f, 0.0f, 0.0f,
		0.0f, 0.0f, 1.0f, 0.0f,
		eye.x, eye.y, eye.z, 1.0f
	);

	return OrientInverse * TranslateInverse;
}

That is probably the most difficult part of doing shadow mapping and other real time techniques (once you get past all of the theory, that is). And look, it’s all wrapped up in a tiny function! Store that into a texture matrix and your shaders have quick and easy access to world space.

So, the question is, what can I conjure up to make my life easier in the future. First, a solid login system is needed. Also, a way to organise sections of the site, including subsections. Each section should provide title text, breadcrumb text, menu text, content, edit content forms, templates and so on. Finally, a site object has to tie everything together.

This needs to be very freeform. First, the login system. EVolt has a good rundown that I think I’ll gut and modify to my liking. In its current form, it has too much involvement with the form object. Next, I need to create a Section class. It needs the following:

• Variables
• title_text
• menu_text
• breadcrumb_text
• id
• template
• subsections
• content
• is_current
• database
• Methods
• Section()
• get_content()
• add_subsection(section)
• set_current()
• draw()

The main Site class should be similar to Section, but act more as a wrapper and tell which section is current. That might be able to work.

Set Up

In this example I will be using OglExt, but there are many different extension managers out there and all are easy to use. I like OglExt because it doesn’t require an initialization step like the OpenGL Extension Wrangler requires. I will also be using GLWindow as it is an easy to use OpenGL framework. This example works just as well in GLUT or any other window manager you can find. Here is the main file that we will be working with. Each step is outlined.

#include "GLWindow.h"
#include
#include
#include
#include

// Set Window size
window->starting_width = SIZE;
window->starting_height = SIZE;
window->mainLoop(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
}

Read more about GL_ARB_depth_texture