Is glm::ortho() actually wrong?

Question

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?

score 72 · Accepted Answer · answered Sep 01 '12 at 18:40

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 );

Instead of appending `.f`, you can also explicitly specify the template you're looking for: `glm::ortho(...)`. I think it'd also work with just one argument made an explicit float. — Nic, May 26 '18 at 16:53
FWIW for future readers, make sure your `zNear < 0.0f` and `zFar > 0.0f`. When switching from ortho to perspective, glm calls `glm::radians(fov)` for its parameter and you switch `zNear > 0.0f` and `zFar > zNear`. Your parameter for aspect ratio might be off also due to the final result not being float. Also, OpenGL uses the `glm::orthoLH` and `glm::perspectiveLH` prototypes, which are default. — user2262111, Feb 06 '19 at 21:38

Is glm::ortho() actually wrong?

1 Answers1