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?
glm::orthoSpecifies a logical 2D coordinate system which is to be mapped into the window positions indicated. Often one matches the coordinates to match the size of the window being rendered to. In the template glm::ortho is used for 2D rendering of text.
The glOrtho subroutine describes a perspective matrix that produces a parallel projection. (Left, Bottom, -Near) and (Right, Top, -Near) specify the points on the near clipping plane that are mapped to the lower left and upper right corners of the window, respectively, assuming that the eye is located at (0, 0, 0).
In computer graphics, one of the most common matrices used for orthographic projection can be defined by a 6-tuple, (left, right, bottom, top, near, far), which defines the clipping planes. These planes form a box with the minimum corner at (left, bottom, -near) and the maximum corner at (right, top, -far).
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 );
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With