Question

I’m implementing my own matrix math for an OpenGL application. So far, things are largely fine, although difficult. My most recent issue, one I’ve not had much luck on getting an explanation or a specific problem pointed out to me, is to do with my implementation of glOrtho().

Specifically, my version results in the matrix[14] element being negative zero. (-0.000000) while the version that I glGet() from OpenGL after using the deprecated glOrtho() is a normal zero. (0.000000)

I don’t know if this affects things any, but I am disturbed by my math not matching.

glOrtho’s OpenGL specification, for reference, which I believe I’m following properly, and doing the math correctly for:
http://www.opengl.org/sdk/docs/man/xhtml/glOrtho.xml

My own glOrtho function:

vec_t* Utils::OrthoMatrix(vec_t* out_matrix, const vec_t& left, const vec_t& right, const vec_t& bottom, const vec_t& top, const vec_t& znear, const vec_t& zfar)
{
    memcpy(out_matrix, zeroMatrix, 16*sizeof(vec_t));

    out_matrix[0] = 2.0f / (right - left);
    out_matrix[5] = 2.0f / (top - bottom);
    out_matrix[10] = -2.0f / (zfar - znear);
    out_matrix[12] = -((right + left) / (right - left));
    out_matrix[13] = -((top + bottom) / (top - bottom));
    out_matrix[14] = -((zfar + znear) / (zfar - znear));
    out_matrix[15] = 1.0f;

    return out_matrix;
}

My resizing function(stripped down considerably for readability):

void GameLogic::OnResize(int width, int height) // For purposes of this test, width = 640, height = 480.
{
    if(height == 0) // Avoid potential divide-by-zero
        height = 1;

    glViewport(0, 0, width, height);

    Utils::OrthoMatrix(m_orthoMatrix, 0.0f, (GLfloat)width, (GLfloat)height, 0.0f, -100.0f, 100.0f);

    // Setup fixed function OpenGL to compare against.
    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    glOrtho(0.0f, (GLfloat)width, (GLfloat)height, 0.0f, -100.0f, 100.0f);

    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
}

void GameLogic::Render() // Drastically cut down to illustrate issue.
{
    vec_t modelviewmatrix[16], projectionmatrix[16];
    glGetFloatv(GL_MODELVIEW_MATRIX, modelviewmatrix);

    glGetFloatv(GL_PROJECTION_MATRIX, projectionmatrix);
/*
    At this point, projectionmatrix and m_orthoMatrix are identical, 
    except in the matrix[14] element, which is 0.000000 for projectionmatrix, 
    and -0.000000 for m_orthoMatrix.
*/
}

I can’t quite figure out why this could be, or what it effects? The math checks out as correct as far as I can see, so it should be negative zero, yet OpenGL is returning positive zero. My best guess so far is some sort of driver quirk where the driver is fudging the numbers to avoid negative zero? I’ve tested this code on two separate nVidia GPUs and gotten the same result. Don’t have access to something ATI or similar to test with too.

Disclaimer: I’m somewhat clueless as to how glOrtho’s near and far values work, although the specification does specify that negative values are allowed.

Should I be initializing my projection matrix with an identity matrix, or multiplying an identity matrix into the perspective matrix? I don’t…think I need to do that, and my glFrustum implementation appears to have been working okay without doing that, but maybe that’s it? I don’t understand the math well enough to know if that should be done for correctness or not.

Any ideas, anyone, on what I’m doing wrong or misunderstanding? Or if I’ve indeed found some sort of odd quirk? An explanation of what, if anything, using negative zero might effect would be good, as well, if it’s advised that the best course is to just go with it, rather than try to adjust the values from what I’m currently getting?

Answer 1

Don’t try to “fix” it — your code is working correctly. “Odd quirk” covers it nicely, I think.

Adding either zero to anything other than zero (which is what matrix multiplication does) yields exactly the same result; this doesn’t even count as a significant discrepancy.

And, practically speaking, you should expect to encounter discrepancies when comparing two different floating point procedures that compute the same nominal result. Floating point is not exact, so anything you do differently (changing the order of addition, for example) will likely yield a slightly different result. Consequently, whenever you compare floating point results, you need to specify a tolerance.