# Why I hate glOrtho and all its offspring

In case you’re not familiar with the glOrtho function from OpenGL, it constructs and stores in to the active matrix a “parallel” projection matrix that is orthogonal to the screen. The function looks harmless enough:

glOrtho(left, right, bottom, top, near, far);

But the devil is in the details. The details are right here by the way, oh and also over at Microsoft’s version.. we’ll come back to Microsoft’s version shortly.

A typical call to this function might look like this:

glOrtho(0, 640, 0, 480, -1, 1);

Usually, the values 640 and 480 are replaced with the actual size of your window or widget. Let’s take a side step for a moment and upgrade to OpenGL 3.2 and ditch glOrtho and instead of glm:ortho<float>. This is an identical function and the matrix is still the same. In case you didn’t follow the link to the documentation to see the matrix, here it is:

(*image belongs to Microsoft)

So my gripe with this function is the way in which near and far are treated. Imagine we have just set up our ortho matrix and we have a near of -1 and a far of 1. Theoretically, if you wanted to put something *close* to the viewer on the screen, you’d want to put it nearer the *near* value, right? so you’d put it at -1. Oh my, have I expected near to mean near and failed miserably? Why yes, yes I have.

You see, the matrix described here actually flips the signedness of the near and far values. You can see it in the matrix above with the -2 instead of a 2. Why? Heaven knows, you’d have to dredge up the history of 3d rendering and go back to the teapot designers to find out why it was done this way. The downshot is that if you want to put something *near* the viewer, you have to give it a value near the *far* value.

Confused? You should be. It gets worse. If, for some reason, you went to the Microsoft webpage on glOrtho you would be still scratching your head. You see, the two pages differ ever so slightly in one crucial sentence:

Microsoft: “The *far* parameter specifies the location of the far clipping plane.”

Khronos.org: “-`far`

specifies the location of the far clipping plane.”

Microsoft makes the rookie mistake I made years back when I first encountered this function, that far means far and near means near. Only the authors of the opengl spec get this right. Someone at Microsoft didn’t copy and paste, or perhaps thought that pesky little ‘-’ was a typo. Either way, it’s not unreasonable for someone new to opengl to rage a little on this particular matrix.

So why rant about it now? Because I fell for it -again-. AGAIN.. after all these years and knowing full well how stupid this little function is, I fell for it again when I dumbly assumed it would behave more sanely in glm::ortho. I found a curious bit of code in my renderer that had near and far back to front and I couldn’t figure out why. After toying with it a while I finally figured it out and that is what sent me straight to the blog to write some abusive words about this matrix.

Hey ortho matrix, go back to negative space where you belong!