Is glm::ortho() actually wrong?

Jamie Syme picture Jamie Syme · Sep 1, 2012 · Viewed 30k times · Source

I recently thought it would be a good idea to switch from the old (deprecated) functionality that OpenGL provides, such as matrix operations and the fixed function pipeline.

I am using GLM as my matrix library to simplify things a bit. The problem is that it may have caused more problems than it simplified...

Perspective projections worked fine with my shaders and setup, but when I tried to switch to orthogonal, everything broke down. My points and simple quads wouldn't display. When I used the old OpenGL matrices, things started working again.

I narrowed it all down to the projection matrix. Here is how I called it:

glm::mat4 projMat = glm::ortho( 0, 400, 0, 400, -1, 1 );

I compared that to the one supplied by opengl once this is called"

glOrtho( 0, 400, 0, 400, -1, 1 );

The only differences are the [0][0] element and [1][1] element (which, as far as I know, be equal to "2/width" and "2/height", respectively). From the OpenGL matrix, the values were exactly that! On the glm matrix, though, the values were 0.

Once I manually switched the values from the glm matrix after I called glm::ortho, everything was working again!

So my question: is the glm::ortho() function really broken, or am I just using it wrong?

Answer

Tim picture Tim · Sep 1, 2012

It doesn't appear that it should be broken from the source code (v 0.9.3.4)

template <typename valType> 
GLM_FUNC_QUALIFIER detail::tmat4x4<valType> ortho
(
    valType const & left, 
    valType const & right, 
    valType const & bottom, 
    valType const & top, 
    valType const & zNear, 
    valType const & zFar
)
{
    detail::tmat4x4<valType> Result(1);
    Result[0][0] = valType(2) / (right - left);
    Result[1][1] = valType(2) / (top - bottom);
    Result[2][2] = - valType(2) / (zFar - zNear);
    Result[3][0] = - (right + left) / (right - left);
    Result[3][1] = - (top + bottom) / (top - bottom);
    Result[3][2] = - (zFar + zNear) / (zFar - zNear);
    return Result;
}

My only thought is that this template might be creating a matrix of integers (as you've passed all ints to the function), and thus doing integer division instead of floating point. Can you try appending .f to all your parameters?

glm::mat4 projMat = glm::ortho( 0.f, 400.f, 0.f, 400.f, -1.f, 1.f );