glm::perspective

OpenGL OpenGL: Basic Coding
1

Hi folks,

I’m trying to move my gluPerspective() code over to glm’s perspective(). However, using the same values does not provide the same draw. As an example:


// using #define GLM_FORCE_RADIANS
// variable fov is a float as radian (35 degrees converted)
glm::perspective(fov,(float)width / (float)height,0.1f,1000.0f);

// is not the same as

gluPerspective(35.0f,(float)width / (float)height,0.1f,1000.0f);

Why is this?

WP.

2

There’s no way to tell from the tiny segment of code you’ve provided us. For example, you say that fov is 35 degrees in radians. That’s nice but if your bug is in your degrees-to-radians conversion, how could we possibly tell without seeing it?

Further, you haven’t shown how you use these two matrices. gluPerspective doesn’t just compute a matrix after all. It multiplies the generated matrix with the current OpenGL matrix, replacing it on the current matrix stack. Which means that fixed-function OpenGL rendering (or shader rendering if the shader uses compatibility uniforms) you perform afterwards will use this matrix.

[var]glm::perspective[/var] only computes a matrix. If you don’t capture its return value in a variable (which your example code does not) and pass it to OpenGL in some fashion… then you haven’t actually done anything OpenGL could possibly notice.

Also, please note that there are virtually no GLM functions that actually talk to OpenGL. Despite the name, it doesn’t directly affect any OpenGL state. GLM is a vector math library designed to look like OpenGL and GLSL.

Talking to OpenGL and GLSL is still your job.

In short, you can’t do a 1:1 replacement of OpenGL matrix functions with GLM matrix functions. You have to store the GLM matrices and give them to OpenGL to actually use.

3

Hi Alfonse,

I can see that the radian is right - I can print it. Didn’t worry about mentioning it above. I had also been capturing the return for glm’s perspective, again I didn’t worry about it in the above. Was looking for the simple approach.

[QUOTE=Alfonse Reinheart;1266205]
glm::perspective only computes a matrix. If you don’t capture its return value in a variable … and pass it to OpenGL … then you haven’t actually done anything OpenGL could possibly notice.
…
In short, you can’t do a 1:1 replacement of OpenGL matrix functions with GLM matrix functions. You have to store the GLM matrices and give them to OpenGL to actually use.[/QUOTE]

That’s what I was after - cheers!

WP.

4

Alright, this has made things very messy my end. I come from the old school side of the fence when we could work with just xyz, as in animation 3d viewport 3 floating values. I kind of understand how the matrix data works, but am having a rough time converting it over properly. I’ll refrain from piling on the questions, but I’ll start with a few and see where they take me - bare with me here.

  1. What/how many matrix variables do I need in order to work with both ortho and perspective views? I have the following, will these cover my needs:

	glm::mat4 projectionMatrix;
	glm::mat4 viewMatrix;
	glm::mat4 modelMatrix;
	glm::mat4 WorkingMatrix;
	
	// These are ogl window class level variables. The idea being to fill the first 3 with appropriate values, and put them all in the forth to keep everything in it's own object
  1. Is using glUseProgram(0) enough (and forwards compatible) for ogl versions that have deprecated default things? If not, is there a default shader floating around I can take advantage of? If using glUseProgram(0) is fine, then what can we use in place of glMultMatrixf/glLoadMatrixf() if we’re not using a ‘default’ shader of our own?

WP.

5

The whole point of using shaders is that you decide what you need. How many variables you “need” depends entirely on what you want to do and how you want to do things.

Also, I fail to see how the number of matrix variables has anything to do with whether a projection is orthographic or perspective. The matrix math is the same either way. The orthographics vs perspective distinction is about what data you put into the matrix; how you use it remains the same either way.

If you are using core profile OpenGL, glUseProgram(0) means that no program is bound to the OpenGL context. Attempting to render without a program (or a program pipeline) will result in an error.

There is no such thing as a “default” shader; again, the whole point of shaders is that you get to define how they work. Which means that you have to define how they work.

I’m sure you could find some shader online that emulates the old fixed-function pipeline in some regard.