Hi All,

I'm reading the tutorials from learnOpengl site (nice site) and I'm having a question on the camera (https://learnopengl.com/Getting-started/Camera).

I always saw the camera being manipulated with the lookat, but in tutorial I saw the camera being changed through the MVP arrays, which do not seem to be camera, but rather the scene that changes:

Vertex Shader:

#version 330 core
layout (location = 0) in vec3 aPos;
layout (location = 1) in vec2 aTexCoord;

out vec2 TexCoord;

uniform mat4 model;
uniform mat4 view;
uniform mat4 projection;

void main()
{
	gl_Position = projection * view * model * vec4(aPos, 1.0f);
	TexCoord = vec2(aTexCoord.x, aTexCoord.y);
}

then, the matrix manipulated:

.....
glm::mat4 projection = glm::perspective(glm::radians(fov), (float)SCR_WIDTH / (float)SCR_HEIGHT, 0.1f, 100.0f);
ourShader.setMat4("projection", projection);
....
glm::mat4 view = glm::lookAt(cameraPos, cameraPos + cameraFront, cameraUp);
ourShader.setMat4("view", view);
....
model = glm::rotate(model, glm::radians(angle), glm::vec3(1.0f, 0.3f, 0.5f));
ourShader.setMat4("model", model);

So, some doubts:

- Why use it like that?

- Is it okay to manipulate the camera that way?

-in this way, are not the vertex's positions that changes instead of the camera?

- I need to pass MVP to all shaders of object in my scenes ?

What it seems, is that the camera stands still and the scenery that changes...
it's right?
 

Thank you

You can premultiply your model view projection matrices, so that you only have to pass one matrix into the shader:

ModelViewProjection = projection * view * model

As for what's happening here, the View matrix there is the camera you are used to manipulating (note that its even configured with lookAt).

So you have the model matrix, one for each object in your world. It defines the location of the object in the world (more formally, it defines a transformation from model-local space to world space).

You have your camera (view) matrix, which defines the transform from world space to camera-locale space.

And you have your projection matrix, which defines the transformation from camera-local space to screen space (technically clip space, but its close enough for now).

When you multiply these all together, you have a combined ModelViewProjection matrix, which transforms directly from model-local space to clip space, in one operation.

And, obviously, since the model matrix is different for each object in your world, so too will be the combined ModelViewProjection matrix, so you'll be passing a *different* matrix into the shader of each object in your scene.

I think the term camera is a bit missused here because you wont have any kind of camera. A camera also cant do rendering that is what GL does with or without camera.

I see this in engines like Unity or Unreal so people get a wrong feeling of what a camera really is.

What you do have is your hardware that fills a buffer with pixels to be displayd on the screen but how does it do that; It takes the position of every vertex that is defined by a set of coords and rasterizes these into that buffer. Now the rendering hardware needs to know how this should be done. Ever used rendering without telling GL what your base matrices are?

If you see anything except the screen color then it dosent look like you expect. Thats because the coord system you use and that one that the renderer use are totally different. This is the point where your matrices come into the game. A matrix is an array of NxM length (mostly 4x4 in 3D rendering) that multiplied by a given point tells the graphics card where the vertex belongs to. As basic setup this will be a projection matrix because your screen isnt 3D at its own, this is where the z-buffer is introduced so that hardware can determine what should be rendered, what is hidden by another one, and the identity matrix.

These two matrices mean "read": Take my 3 dimensional vector (x, y, z) and transform it based on my world origin (aka the camera or view from which we see the world) and map the result onto my screen where my aspect ration and perspective determine how you should do that. A 3D projection matrix also is responsable for let far objects seem farer away as near objects.

Just to know

You do not need a model matrix per se because vertices may also be placed in world instead of local space. Rendering a quad at (-1,1,1)(-1,-1,1)(1, -1, 1)(1, 1, 1) in world coords is the same as if you render it at origin (without z transform) in local space and have a 1 step z transform in your model matrix

Hello swiftcoder and Shaarigan.

Thank you for your replys.

i understand now, but my question is the standardization of how to projection/design.

When I started learning opengl and it was with GLUT, so, I used glutLookAt and did not send any matrix to SHADER, and all objects added in the scene rendered normally.

In modern openGL, Is that how I should make my projection? (with MVP in vertex shader) ?

Thank you

4 hours ago, RenanRR said:

In modern openGL, Is that how I should make my projection? (with MVP in vertex shader) ?

Yes.

4 hours ago, RenanRR said:

When I started learning opengl and it was with GLUT, so, I used glutLookAt and did not send any matrix to SHADER, and all objects added in the scene rendered normally.

In the (long deprecated) OpenGL immediate mode, GLUT/OpenGL just managed the MVP matrix for you. The underlying math is identical, however.

In addition to the more detailed explanation of what a camera is, it can be helpful to think of a camera as just a logical representation of where you are looking in a scene. Although a "camera" doesn't actually exist in game engines, it is pretty common to create a class for one and have rendering functions accept a camera as a logical viewpoint for the rendering. In unreal and such you'll see the camera also contains settings about how the scene should be rendered, specifically any properties that are endemic to the camera itself. This has the advantage of making it easy to create different logical cameras and both manipulate them and swap the viewpoint easily.

More generally:

• The model matrix is the position of the model in world space, as opposed to its local space.
• The view matrix is essentially the viewing position of the camera.
• The projection matrix is how the camera augments the view, you can think of it like using a different lens in a real camera, usually this is orthographic or perspective, but it also contains properties about the viewing space such as the aspect ratio and the clipping plane.

Ok, but how should I call the camera? What other name or term should I speak?

Projection ?

1 minute ago, RenanRR said:

Ok, but how should I call the camera? What other name or term should I speak? Projection ?

The camera is still a camera. I'm not sure why you think it shouldn't be?

Modern OpenGL follows the exact same concepts as legacy OpenGL. It just exposes you to a lot more power, and in doing so makes you take on more responsibility.

6 minutes ago, swiftcoder said:

I'm not sure why you think it shouldn't be?

 

Hi swiftcoder, sorry.

because Shaarigan said: 

Quote

I think the term camera is a bit missused here because you wont have any kind of camera. A camera also cant do rendering that is what GL does with or without camera.

I see this in engines like Unity or Unreal so people get a wrong feeling of what a camera really is.

I got confused a bit in the expressions and terms.
 

3 minutes ago, RenanRR said:

I got confused a bit in the expressions and terms.

Shaarigan is being a bit... overly reductive. It's perfectly idiomatic to call the thing that manages the View+Projection matrices a "camera".