How much matrices should I use for OpenGL transformation?

Question

As I start to get some deeper(or at least a little bit better) understanding on how camera transformations works, I am curious about one thing: How much matrices should I use ?

I mean, until now I have been working with simple 2d ortho projection and I was using world positions (not in range -1.0 to 1.0 ) so I just created a matrix at the start of the program and that was it but when I wanted to get more to 3D(to get same effect of not using NDC) I noticed (in tutorials) that they use a lot of matrices(for example : they create matrix for every object ingame for translation and then send it to the GPU). This confuses me because I thought that I will use only 3 matrices (for every transform step). Can you explain me how is this done in professional games? Do I need to load new model matrix for every object(send it to vertex) ? Or change the whole MVP matrix in shader with every object being rendered? Is it still sufficient? Thanks

Edit About efficiency : Is it efficient to change the shader variable that often ? I mean, I want use my batch system from my old code and it looks like this now:

1. Bind texture + VAO
2. Render object.1+object.n via glDrawArrays/Elements/Instanced

But what about now it would be :

1. Bind texture + VAO
2. Load model matrix of object.1(via glUniformMat4fv) and render it, then load another model matrix for object2 and same for every object in batch

Isn´t it inefficient to change shader variable that much ?

Answer 1

Your object is transformed in multiple steps, and for each step, you usually use a matrix.

• You can rotate, scale and translate every model. This can be done with three separate matrices, but usually those three operations are combined into one big transformation/model matrix, which does everything together. Every model has it's own transformation matrix.
• The object is now in the correct "world space". The next step is the camera transformation. When you move your camera, the whole world is transformed, and this is a single matrix that gets applied to every object you want to render. ("You position the object according to your camera")
• The last matrix you need is a projection matrix. This takes your 3D model, and creates a "depth", i.e. projecting the 3 dimensions to a 2 dimensional screen. You can think of it as scaling all the x,y coordinates according to the z coordinate to appear nearer/further.

In general, you create your matrix, and send it to your shader, where all the matrices are applied to the vertices. The GPU is very good at parallelising the work, so you don't spend precious CPU cycles doing the matrix multiplications yourself.

For more information and an actual implementation Another tutorial about a simple ray picker, which describes the transformations in openGL.

Answer 2

In professional games every object in the world will have its own world matrix. This is usually stored in some structure that represents your entity in the world, or some component hanging off that entity (A class, struct, etc).

The world matrix isn't just used for graphics, a lot of gameplay logic will rely on it too. This matrix will ultimately get passed through to the rendering API in some form.

I'm very out of touch on the graphics side, but I think typically, matrices for rendering get passed through as parameters to the vertex shader, and the matrices that get passed through will typically depend on the needs of the vertex shader. If the logic in the vertex shader needs access to the world, view and projection matrices separately, then they'll be passed in separately. If the logic in the shader really only needs the combined Model * View * Projection matrix, then it might get passed in that way to cut down on computation in the shader and the number of constants that need to be set.

Some graphics techniques may even pass in vertices in world-space or camera space, if that makes sense. That would be more unusual though, for one-shot effects rather than objects that want to share the same vertex buffer. Dynamic effects like particle systems are a good example here.

Typically in a professional quality engine, the way the data is passed through to the graphics API will often vary based on object/material type. Terrain for example, or other types of static world geometry will be very different to dynamic entities, skinned characters, etc. Unlit geometry might require less information than geometry that's affected by lighting, etc.