So, basically: *Model matrix:* defines position, rotation and scale of the vertices of the model in the world. *View matrix:* defines position and orientation of the "camera". *Projection matrix:* Maps what the "camera" sees to NDC, taking care of aspect ratio and perspective.
@@plaigon5219 Yeah, but actually no. The MVP matrix is sent to the shader per one draw call, as set by uniform. One will issue a draw call per model that you want to draw. The projection matrix changes when window is resized. The view matrix is changed for camera movement (per frame) and model matrix is taken from model itself. Then the MVP matrix is constructed by multiplying and bind to uniform. So each model has its own "transform" matrix, that is then applied with the rest *just before* the draw.
What are you talking about? The model matrix is different for every object with a different position orientation or scale. If you don't want all of your models to be at the same spot you have to have different model matrices for each one.
Tip about cameras for anyone, You can do regular transformations on a "Camera" object as you would your model. Right before its time to render your scene, you can calc the transformation matrix(trans, scale, rotate) for the camera as you would a model, BUT take the extra step of doing an inverse operation on the matrix, which flips everything for you, left goes right, rotate up goes rotat down, etc. Its good to keep both Matrices around because you need the Original for Mouse Ray casting and you can can pull the Right, Top, Forward Direction vectors straight out of the matrix as each column (or is it row) is a the world direction that your facing. Important information for First Person Movement. Side note, setting up a Uniform Buffer Object (UBO), you can upload some of that data once and have it accessible in all your shaders. Makes things easier then pushing Projection and View matrices to every shader. There is other good bit of data to pass to a UBO, camera position for lighting calcs, a time value for animations, screen width and height for some effects, to name a few. The best part of the video is when Cherno said "Its hard to teach opengl"... Boy I can sympathize with that, a pain to explain abstract concepts sometimes.
No prob. They can be tricky since you need to lay out data in chunks of 16 bytes. So Vec3 + Float != Float + Vec3. There is a thing where you can't use a vec3 at the end of that chunk of 16 bytes, So to lay out the memory as Float then Vec3, you need two chunks where the first 4 bytes filled in for the float, the remaining 12 are left as empty space then a new chunk is created that uses the first 12 for the vec3 then the last 4 bytes are empty. BUT if you lay it out as Vec3 + Float, then you can get away with only 16 bytes instead of 32, which the 32 bytes will have half of it as just wasted space Matrices follow similar rules. Mat4x4, fills out 4 chunks perfectly, but a Mat3x3, you need three chunks but each one will have 4 bytes of wastes space, totally at12 bytes of wasted space but there isn't anything you can do about that. Now this is how it is for WebGL and OpenGL ES 3.0. Not sure if the rules related to OpenGL 4 has changed for UBOs. So yea, when you read up and play with them, just make sure you read about how to order and layout the data because if you do it wrong, its very hard to debug.
Omfg I hate acronyms. I thought this video was going to be on minimum viable Product but I guess you're the most valuable player in teaching me about model view projection.
For real, you are my hero. This content is absolute gold. I'm taking an online course on edX, and it is(to a BONKERS degree) absent the requisite information to do its own homework... You are really making these concepts more palatable for someone learning the ropes. Thanks so much!
영어공부 + OpenGL 공부 일석이조군. Kill two birds with one stone . English + OpenGL.. Also your explanation, makes my head clear of concept of matrics that I 've been ambiguous for a long time, thanks Cherno.
dude you just opened my eyes. thanks. I cant really believe that what you explained in this and the last video are what make the whole thing come together. Thank you .And the probable reason why nobody thought you this way is that they never understood it properly in the first place. I came to your videos for a college opengl project and im definitely interested now. Thank you so much.
I think i have a good example which makes it a bit clearer, what the model matrix is good for. Usually, you define the vertices with the center being at 0,0,0 and the coordinates being normalized, this means ranging from 1 to -1. Then you can draw different models at different positions, with different sizes and rotations, but with the same vertex buffer by just changing the model matrix. It is more efficient to multiply the vertices by the matrix in the vertex shader than to change the vertices on cpu side.
If anyone has trouble understand why Model, View and Projection matrices in OpenGL are multiplied in reverse order, consider this: 1. model vertex "v" is multiplied by Model matrix first: v1 = M * v 2. result of previous step is multiplied by View matrix: v2 = V * v1 = V * (M * v) 3. like before, result is multiplied by Projection matrix: v3 = P * v2 = P * (V * (M * v)) we can rearrange parenthesis and concatenate 3 matrices into one: v3 = (P * V * M) * v = MVP * v MVP = P * V * M hope this explain why matrices are multiplied in reverse :)
I like your videos gives good basic idea about the basic constructs of opengl and really look forward for more videos where you get deep in these topics.
guys, i had my m*v*p backwards (p * v * m), and couldn't figure out why my math was being weird for DAYS, order MATTERS A TON with matrix multiplication people!!!
10:40 Isn't it better to do the matrix multiplication in the shader code? Or are we doing it on CPU because the "camera" is not moving so we only have to multiply once?
It has been one year, so hopefully you got an answer. Matrix multiplication will always be faster on the CPU. Vertex shaders get run multiple times, and if you multiply the matrices together in the shader, you would be getting the same result every time the shader was run. If you multiply them on the CPU, the matrices will only be multiplied once, and then you can pass it into the shader via a uniform.
I've tried the same as you and I got a strange trapeze. After debugging I found out that there was a bug in the shader. I wrote gl_Position = position * u_MVP;. but as a swapped position and u_MVP it worked perfectly. But I don't understand why. I tought in multiplications it doesn't care where to put what number. Even if it's an matrix.
Matrix multiplication is different than our normal scalar(or number) multiplication. It's hard to explain in a comment but you can check any matrix multiplication video to get an idea. Basically, when two matrices are multiplied, they are "NOT" multiplied elementwise but row elements(R1) of the first matrix are multiplied with corresponding column(C1) elements of the second matrix and the results are added to get the matrix element R1C1 of the resultant matrix. So, if we reverse the order, we get entirely different results. That's why it is said that matrix multiplication is not commutative. Hope that makes sense.. This comes under the "LINEAR ALGEBRA".. Better watch a video.. :p
Can we use openGl functions for matrix(glTranslate, glScale, glRotate) with only Ortho matrix? Or if we provided orthographic matrix we must use MVP matrices?
I don't understand. Isn't moving the camera to x = -100 moving it to the left? Yet the object did move to the left. It should've moved to the right closer to the center of the window. Unless the camera is at like -480 (half of 960 which is our windows width)
don' really get why the order of multiplication of mvp should depend on whether row major or col major storage is used, what's just internal storage and should change the result of multiplying matrices
glm::perspectivefov(); however you will then have to put your objects in further away from the origin otherwise you wont see anything because by default in opengl the camera is in the origin looking in -z direction. you can do this by either translating you object into -z or simply define the object coordinates (positions[]) already a bit further in -z direction.
The mapping to (-1, 1) doesn't work for me !!! The PAIN!!!!!!!!!!!!!!!! It's so weird because I have to adjust the numbers differently, to be in (-1, 1), for the view & model matrix!
What does the matrix multiplication order have to do with column-major/row-major? I don't quite get that. Multiplication order should stay the same, since matrices themselves are not actually column or row-major, just the data layout.
That 4x4 grid of a 2D array is just a 16 element array and your compiler just converts it to such anyway. He gave your answer above as to what the difference between the two are.
Preface: If this is confusing it might just be my explanation or my practically non-existent drawings, ask the question on Cherno's discord and you'll hopefully get a better answer (And maybe even some drawings) Draw two matrices like this: A = | 1 2 | | 3 4 | And B = | 5 6 | | 7 8 | If you multiply those together, AB, the upper-left number of the result will be 1 * 5 + 2 * 7 (If you don't see why, just look up matrix multiplication and try until you get it). Now write them in row-major form, with parentheses to denote which numbers were involved in the calculation: A = (1), (2), 3, 4 and B = (5), 6, (7), 8 Now write them in column-major form, with parentheses for the numbers we WANT to be involved in the calculation: A = (1), 3, (2), 4 and B = (5), (7), 6, 8 Now the algorithm we use will ALWAYS take the 1. and 2. numbers (in the array corresponding to the array) in the matrix to the left, and the 1. and 3. numbers of the matrix to the right, we know this because that's what it did when we calculated AB. Since the algorithm doesn't know if the matrix is row- or column-major. As you hopefully can see this means that to get the numbers we want we now have to multiply them as BA, since that'll take the first two numbers from B (5 and 7) and the first and second number from A (1 and 2), which will give the same answer as the calculation we did with row-major. This proves that when you switch from row-major to column-major and vice-versa you also change the "direction" of the multiplication. I gloss over it here, but it always multiplies the first two numbers from each matrix, and the second two numbers from each matrix together, so the result will be the same, since the order is 1, 2 and 5, 7 in both cases
I have been binging the C++ series and this now three years later and like watching Cherno slowly become an alcoholic. Also, what is this soundtrack I like it?
Great video ! However, I thought you would create the functions yourself and not tell us "use glm and that's it", if we want to use another library or switch of language your video can become unnecessary (only for the coding part I agree, the explications are good :) )...
The sense of own matrix function only for education and understanding how it works. In other situations someone made those functions for you, so u can just include lib and work with it.
I appreciate your work, and I like your way of teaching, so could you please make some tutorials of x86 Intel assembly, because I haven't found a very good source to learn it.
idk how helpful this is, but if you google "game engine architecture pdf", you can find the whole 800+ pages online for free and that book obviously has materials about game engines, which seems to be what you're looking for
So, basically:
*Model matrix:* defines position, rotation and scale of the vertices of the model in the world.
*View matrix:* defines position and orientation of the "camera".
*Projection matrix:* Maps what the "camera" sees to NDC, taking care of aspect ratio and perspective.
Does that mean that there is a single one model matrix for thousands of 3d models that a modern game can have?
@@plaigon5219 yeah
@@plaigon5219 Yeah, but actually no. The MVP matrix is sent to the shader per one draw call, as set by uniform. One will issue a draw call per model that you want to draw. The projection matrix changes when window is resized. The view matrix is changed for camera movement (per frame) and model matrix is taken from model itself. Then the MVP matrix is constructed by multiplying and bind to uniform. So each model has its own "transform" matrix, that is then applied with the rest *just before* the draw.
What are you talking about? The model matrix is different for every object with a different position orientation or scale. If you don't want all of your models to be at the same spot you have to have different model matrices for each one.
@@sweetberries4611 No.
you da real mvp for making these videos, thanks!
Nice
Thats smooth
Took the words out of my mouth!
After 6 years this guy is still making sure I learn OpenGL
Tip about cameras for anyone, You can do regular transformations on a "Camera" object as you would your model. Right before its time to render your scene, you can calc the transformation matrix(trans, scale, rotate) for the camera as you would a model, BUT take the extra step of doing an inverse operation on the matrix, which flips everything for you, left goes right, rotate up goes rotat down, etc. Its good to keep both Matrices around because you need the Original for Mouse Ray casting and you can can pull the Right, Top, Forward Direction vectors straight out of the matrix as each column (or is it row) is a the world direction that your facing. Important information for First Person Movement.
Side note, setting up a Uniform Buffer Object (UBO), you can upload some of that data once and have it accessible in all your shaders. Makes things easier then pushing Projection and View matrices to every shader. There is other good bit of data to pass to a UBO, camera position for lighting calcs, a time value for animations, screen width and height for some effects, to name a few.
The best part of the video is when Cherno said "Its hard to teach opengl"... Boy I can sympathize with that, a pain to explain abstract concepts sometimes.
SketchpunkLabs I was not familiar with the concept of Uniform Buffers, thanks for bringing that up!
No prob. They can be tricky since you need to lay out data in chunks of 16 bytes. So Vec3 + Float != Float + Vec3. There is a thing where you can't use a vec3 at the end of that chunk of 16 bytes, So to lay out the memory as Float then Vec3, you need two chunks where the first 4 bytes filled in for the float, the remaining 12 are left as empty space then a new chunk is created that uses the first 12 for the vec3 then the last 4 bytes are empty. BUT if you lay it out as Vec3 + Float, then you can get away with only 16 bytes instead of 32, which the 32 bytes will have half of it as just wasted space
Matrices follow similar rules. Mat4x4, fills out 4 chunks perfectly, but a Mat3x3, you need three chunks but each one will have 4 bytes of wastes space, totally at12 bytes of wasted space but there isn't anything you can do about that.
Now this is how it is for WebGL and OpenGL ES 3.0. Not sure if the rules related to OpenGL 4 has changed for UBOs. So yea, when you read up and play with them, just make sure you read about how to order and layout the data because if you do it wrong, its very hard to debug.
Omfg I hate acronyms.
I thought this video was going to be on minimum viable Product but I guess you're the most valuable player in teaching me about model view projection.
15:35
Roses are red
Violets are blue
Your camera is way too far away from you
Surely when he realized that the camera was too far away, he ruined everything. But I cover it with the help of edition 7u7
He pulled the "hold on a minute" on use
For real, you are my hero. This content is absolute gold. I'm taking an online course on edX, and it is(to a BONKERS degree) absent the requisite information to do its own homework... You are really making these concepts more palatable for someone learning the ropes. Thanks so much!
Most valuable player.
영어공부 + OpenGL 공부 일석이조군.
Kill two birds with one stone . English + OpenGL.. Also your explanation, makes my head clear of concept of matrics that I 've been ambiguous for a long time, thanks Cherno.
dude you just opened my eyes. thanks. I cant really believe that what you explained in this and the last video are what make the whole thing come together. Thank you .And the probable reason why nobody thought you this way is that they never understood it properly in the first place. I came to your videos for a college opengl project and im definitely interested now. Thank you so much.
I just learned it in 2020. I don't know what I did 2 years ago. thanks the cherno.
I took this as more depth explanation for what is going on in sparky engine. I like the way you explain things. Thank you for the video :)
I think i have a good example which makes it a bit clearer, what the model matrix is good for. Usually, you define the vertices with the center being at 0,0,0 and the coordinates being normalized, this means ranging from 1 to -1. Then you can draw different models at different positions, with different sizes and rotations, but with the same vertex buffer by just changing the model matrix. It is more efficient to multiply the vertices by the matrix in the vertex shader than to change the vertices on cpu side.
If anyone has trouble understand why Model, View and Projection matrices in OpenGL are multiplied in reverse order, consider this:
1. model vertex "v" is multiplied by Model matrix first: v1 = M * v
2. result of previous step is multiplied by View matrix: v2 = V * v1 = V * (M * v)
3. like before, result is multiplied by Projection matrix: v3 = P * v2 = P * (V * (M * v))
we can rearrange parenthesis and concatenate 3 matrices into one: v3 = (P * V * M) * v = MVP * v
MVP = P * V * M
hope this explain why matrices are multiplied in reverse :)
Matrix multiplication is not commutative
@@EvgeniyMakarov-kd7gi but is associative. The only property used above was associativity. Don't use fancy terms if you don't know what they mean.
Cherno you da real **MVP**
I like your videos gives good basic idea about the basic constructs of opengl and really look forward for more videos where you get deep in these topics.
You did great job with explaining MVP, I've seen few tutorials about this, but yours is the simplest one! Keep it going!
guys, i had my m*v*p backwards (p * v * m), and couldn't figure out why my math was being weird for DAYS, order MATTERS A TON with matrix multiplication people!!!
thank you for the series
how can we add zooming (just add a scale !?)
how can we select an object by mouse (click or window selection)
thanks again
10:40 Isn't it better to do the matrix multiplication in the shader code? Or are we doing it on CPU because the "camera" is not moving so we only have to multiply once?
It has been one year, so hopefully you got an answer.
Matrix multiplication will always be faster on the CPU. Vertex shaders get run multiple times, and if you multiply the matrices together in the shader, you would be getting the same result every time the shader was run. If you multiply them on the CPU, the matrices will only be multiplied once, and then you can pass it into the shader via a uniform.
@@redfire7820 Thanks. Is it not possible to do a single matrix multiplication on GPU?
@@puyadaravi3109 Are you asking if you can multiply matrices together only once on the GPU?
@@redfire7820 Yes
@@puyadaravi3109 If you only had one vertex then yes. But the CPU would still be faster.
This is the best tutorial ever
What is music in beginning?
I've tried the same as you and I got a strange trapeze. After debugging I found out that there was a bug in the shader. I wrote
gl_Position = position * u_MVP;.
but as a swapped position and u_MVP it worked perfectly. But I don't understand why. I tought in multiplications it doesn't care where to put what number. Even if it's an matrix.
Matrix multiplication is different than our normal scalar(or number) multiplication. It's hard to explain in a comment but you can check any matrix multiplication video to get an idea. Basically, when two matrices are multiplied, they are "NOT" multiplied elementwise but row elements(R1) of the first matrix are multiplied with corresponding column(C1) elements of the second matrix and the results are added to get the matrix element R1C1 of the resultant matrix. So, if we reverse the order, we get entirely different results. That's why it is said that matrix multiplication is not commutative. Hope that makes sense.. This comes under the "LINEAR ALGEBRA".. Better watch a video.. :p
@@GARUDA1992152 Thank you good sir
This comment just fixed my code ❤
If you are not able to see the transformation remember to replace the proj with mvp in the SetUniformMat4f
That was my issue also.
Am I moving around in the world, or is the world moving around me?
"The engines don't move the ship at all. The ship stays where it is and the engines move the universe around it." -Futurama
ah yes, the MVP.... most valued player
Bro why did u betrayed niko
Can we use openGl functions for matrix(glTranslate, glScale, glRotate) with only Ortho matrix? Or if we provided orthographic matrix we must use MVP matrices?
incroyable
I don't understand. Isn't moving the camera to x = -100 moving it to the left? Yet the object did move to the left. It should've moved to the right closer to the center of the window. Unless the camera is at like -480 (half of 960 which is our windows width)
We heard about most valuable player indeed :)
don' really get why the order of multiplication of mvp should depend on whether row major or col major storage is used, what's just internal storage and should change the result of multiplying matrices
讲得太清晰了，太本质了，太切中要害了。牛逼啊，太牛逼了。Cherno， 大神无疑了。用简洁的语言把复杂的事情讲清楚，这才是真正的大神啊。
tiananmen square 1989
Can you render a 3D cube with perspective, please.
How do you define your own coordinate range with perspective projection?
glm::perspectivefov(); however you will then have to put your objects in further away from the origin otherwise you wont see anything because by default in opengl the camera is in the origin looking in -z direction. you can do this by either translating you object into -z or simply define the object coordinates (positions[]) already a bit further in -z direction.
How come when i multiply the view matrix, it stretches, rotates and warps the image across the screen? I'm doing exactly what you did.
Can you do a video about using SPIR-V in OpenGL?
YOU ARE THE *MVP* XD
Videos The Cherno announced count: 82337234183742817948827473198374
I was so worried that John Causey was from a tutorial I missed about rendering text.
THANK YOU, you fucking genius thank you
The mapping to (-1, 1) doesn't work for me !!! The PAIN!!!!!!!!!!!!!!!! It's so weird because I have to adjust the numbers differently, to be in (-1, 1), for the view & model matrix!
What does the matrix multiplication order have to do with column-major/row-major? I don't quite get that. Multiplication order should stay the same, since matrices themselves are not actually column or row-major, just the data layout.
It's because in math A * B and B * A are different with matrix multiplication, and row/column major layout change which one we want.
Kostu96 multiplication is independent from how the data is layed out. Matrices are a 4 by 4 grid, not an array.
That 4x4 grid of a 2D array is just a 16 element array and your compiler just converts it to such anyway. He gave your answer above as to what the difference between the two are.
Sedit T I don't get why though. In mathematics you perform the multiplication on grids, not on arrays. Multiplication order still matters.
Preface:
If this is confusing it might just be my explanation or my practically non-existent drawings, ask the question on Cherno's discord and you'll hopefully get a better answer (And maybe even some drawings)
Draw two matrices like this:
A = | 1 2 |
| 3 4 |
And
B = | 5 6 |
| 7 8 |
If you multiply those together, AB, the upper-left number of the result will be 1 * 5 + 2 * 7 (If you don't see why, just look up matrix multiplication and try until you get it).
Now write them in row-major form, with parentheses to denote which numbers were involved in the calculation:
A = (1), (2), 3, 4
and
B = (5), 6, (7), 8
Now write them in column-major form, with parentheses for the numbers we WANT to be involved in the calculation:
A = (1), 3, (2), 4
and
B = (5), (7), 6, 8
Now the algorithm we use will ALWAYS take the 1. and 2. numbers (in the array corresponding to the array) in the matrix to the left, and the 1. and 3. numbers of the matrix to the right, we know this because that's what it did when we calculated AB. Since the algorithm doesn't know if the matrix is row- or column-major. As you hopefully can see this means that to get the numbers we want we now have to multiply them as BA, since that'll take the first two numbers from B (5 and 7) and the first and second number from A (1 and 2), which will give the same answer as the calculation we did with row-major. This proves that when you switch from row-major to column-major and vice-versa you also change the "direction" of the multiplication.
I gloss over it here, but it always multiplies the first two numbers from each matrix, and the second two numbers from each matrix together, so the result will be the same, since the order is 1, 2 and 5, 7 in both cases
I have been binging the C++ series and this now three years later and like watching Cherno slowly become an alcoholic. Also, what is this soundtrack I like it?
my object is experiencing some form of transformation as it get to the edge of the window. help.
nevermind
Make a video on object selection::
Can anyone tell me the model of the phone he has?
Galaxy S8
Great video ! However, I thought you would create the functions yourself and not tell us "use glm and that's it", if we want to use another library or switch of language your video can become unnecessary (only for the coding part I agree, the explications are good :) )...
The sense of own matrix function only for education and understanding how it works. In other situations someone made those functions for you, so u can just include lib and work with it.
I appreciate your work, and I like your way of teaching, so could you please make some tutorials of x86 Intel assembly, because I haven't found a very good source to learn it.
There is an x86 assembly tutorial by a TH-camr named rasim muratovic that I recommend
I want the game Engine series, cherno
What's the Cherno age?
+1 for imgui
Do not write SetUniformMat4f after setting texture ur code will not gonna work
Pleeeeaaaseee..!! Start the game engine series in parallel..
So, do you know any other source from where i can learn game engine developing?
idk how helpful this is, but if you google "game engine architecture pdf", you can find the whole 800+ pages online for free and that book obviously has materials about game engines, which seems to be what you're looking for
thanx
So how's it been going buddy with that book?
Drugs are bad kids
yessss!!! no w can I please has github access :) - I'm Partner on Patreon :)
Please send me a message on Patreon :)
Thx for the vids, but you talk too much, better show us some illustrations
Я знаю, что ты из РОссии, Ян!!!
Давай русские субтитры, плиз!
Ай донт андерстенд Инглиш...
Nooo!!! no 2d plz, only 3D please!!!!