This is a master piece of CG tutorials, anyone into graphics must not miss it. I have been doing graphics for years and I am redoing it from scratch with Brandan's course because there are so many details that we often miss in production. Here it has it all. Congrats again! Hopefully you get back to it for textures someday.
I just got all of this to work on my own earlier today, it was frustrating to debug but I learned a lot about matrix math and coordinate systems. Your implementation is cleaner, as always! Please cover materials, textures, and lighting in later tutorials! And thanks for also releasing the code for this one.
I'm really excited to see where you go with this. I'm currently only starting tutorial 9, but I would love to see this eventually get to loading models and maybe even materials, still a long way off, but this is super cool so far.
My friends, search for your life purpose, why are we here?? I advise you to watch this series and this video 👇 as a beginning to know the purpose of your existence in this life ua-cam.com/play/PLPqH38Ki1fy3EB-8xmShVqpbQw99Do2B-.html ua-cam.com/video/7d16CpWp-ok/v-deo.html
My friends, search for your life purpose, why are we here?? I advise you to watch this series and this video 👇 as a beginning to know the purpose of your existence in this life ua-cam.com/play/PLPqH38Ki1fy3EB-8xmShVqpbQw99Do2B-.html ua-cam.com/video/7d16CpWp-ok/v-deo.html
Another great tutorial! Thanks! I have a quick question though: you mentioned around 4:00 that the matrix multiplication is usually done on the GPU. Wouldn't it make sense to create the final transform matrix on the CPU so that the GPU isn't doing the same operation many times per-vertex?
Ya that’s a very insightful question. I regret not explaining that in more detail now in hindsight. Sometimes in shaders it’s really useful to have the world position of the model before it’s projected into perspective. This can be used for a variety of rendering techniques. So in a shader you will commonly have WorldPosition = modelTransform * vertexPostion; Then do some stuff with worldPostion Then finally gl_Position = projectionMatrix * worldPosition; If you precombine the two matrices you wouldn’t be able to get the world position. I also haven’t explained the viewingMatrix for apply the camera transform but sometimes you want to do stuff within the vertex shader using the position after applying the camera transform as well.
Hi,I was a bit bugged by the resizing of the window and how the cube is resized with it. In the "Viewport transform and the aspect ratio" part as well as the last part I'm not sure if you really wanted the behaviour you got. I specifically mean minute 6:54 or 8:13, where you demonstrate how the cube would be represented with an aspect ratio lower than 1. For the first part, when we call "camera.setOrthographicProjection(-aspect, aspect, -1, 1, -1, 1)" I checked if the aspect ratio was lower than 1, in which case I called "camera.setOrthographicProjection(-1, 1, -1/aspect, 1/aspect, -1, 1)", resulting in the cube getting smaller instead of remaining the same size when resizing the window with a lower width than height. In the same way I modified the "setPerspectiveProjection()" function to consider have an orthographic view volume of at least [left=-1, right=1, top=-1, bottom=1, near=-1, far=1], resulting in: void LveCamera::setPerspectiveProjection(float fovy, float aspect, float near, float far) { assert(glm::abs(aspect - std::numeric_limits::epsilon()) > 0.0f); auto aspect_nominator = aspect; auto aspect_denominator = 1.0f; if (aspect < 1.0f) { aspect_nominator = 1.0f; aspect_denominator = 1 / aspect; } const float tanHalfFovy = tan(fovy / 2.f); projectionMatrix = glm::mat4{0.0f}; projectionMatrix[0][0] = 1.f / (aspect_nominator * tanHalfFovy); projectionMatrix[1][1] = 1.f / (aspect_denominator * tanHalfFovy); projectionMatrix[2][2] = far / (far - near); projectionMatrix[2][3] = 1.f; projectionMatrix[3][2] = -(far * near) / (far - near); } aspect_nominator is the given aspect ratio. But when this is smaller than 1, we must scale it from the width.
Yes this is a good point! Your solution will avoid ever having parts of the view that we want displayed from being cut off as mine does when the height > width
Yup! Also glm is built for openGL which uses a left handed coordinate system and different conventions for the view direction. So using the glm methods results in the y axis getting flipped upside down. If you're making an engine that can run with either openGL and vulkan then using the glm functions makes sense, and in the case of vulkan you can correct the y with gl_Position.y = -gl_Position.y in your vulkan shaders. But since we're doing exclusively Vulkan it made more sense to create our own matrix functions specific to the coordinate system and view direction conventions we are using. For more info see: matthewwellings.com/blog/the-new-vulkan-coordinate-system/
My friends, search for your life purpose, why are we here?? I advise you to watch this series and this video 👇 as a beginning to know the purpose of your existence in this life ua-cam.com/play/PLPqH38Ki1fy3EB-8xmShVqpbQw99Do2B-.html ua-cam.com/video/7d16CpWp-ok/v-deo.html
hmmm is a segfault occuring? You could try running in debug mode with gdb which would isolate the exact location the crash occurs. Alternatively join the dicord discord.gg/CUQkuKsszr and post in debugging help. Myself or someone else is usually quick to lend a hand :)
My friends, search for your life purpose, why are we here?? I advise you to watch this series and this video 👇 as a beginning to know the purpose of your existence in this life ua-cam.com/play/PLPqH38Ki1fy3EB-8xmShVqpbQw99Do2B-.html ua-cam.com/video/7d16CpWp-ok/v-deo.html
The lags are caused by glfw. Essentially when we call glfw poll events the function call blocks while resizing occurs. There are a couple ways around it but the best way is to use multiple threads with one thread always rendering but it adds some other complexity. It’s something I want to do eventually but for the beginner content I’d like to stick with just using one thread.
This is a master piece of CG tutorials, anyone into graphics must not miss it. I have been doing graphics for years and I am redoing it from scratch with Brandan's course because there are so many details that we often miss in production. Here it has it all. Congrats again! Hopefully you get back to it for textures someday.
I just got all of this to work on my own earlier today, it was frustrating to debug but I learned a lot about matrix math and coordinate systems.
Your implementation is cleaner, as always! Please cover materials, textures, and lighting in later tutorials! And thanks for also releasing the code for this one.
Thanks for the video! One thing that tripped me up is that glm is column major i.e. [col][row]. Just in case anyone else gets confused!
that's gotten me before too!
Hello, what is the reason for this?
I'm really excited to see where you go with this. I'm currently only starting tutorial 9, but I would love to see this eventually get to loading models and maybe even materials, still a long way off, but this is super cool so far.
I love this series. Please continue it
My friends, search for your life purpose, why are we here?? I advise you to watch this series and this video 👇 as a beginning to know the purpose of your existence in this life ua-cam.com/play/PLPqH38Ki1fy3EB-8xmShVqpbQw99Do2B-.html
ua-cam.com/video/7d16CpWp-ok/v-deo.html
Late to the party but you just helped me fix an issue I had with my camera where the far had some kind of effect on the near. Thanks so much
Thanks for all your hard work! This was great!
Great job as always, very clear explanations. I'm loving the series.
My friends, search for your life purpose, why are we here?? I advise you to watch this series and this video 👇 as a beginning to know the purpose of your existence in this life ua-cam.com/play/PLPqH38Ki1fy3EB-8xmShVqpbQw99Do2B-.html
ua-cam.com/video/7d16CpWp-ok/v-deo.html
I legit was just coding this last night, what a hell of a coincidence
Excellent video as always
Another great tutorial! Thanks!
I have a quick question though: you mentioned around 4:00 that the matrix multiplication is usually done on the GPU. Wouldn't it make sense to create the final transform matrix on the CPU so that the GPU isn't doing the same operation many times per-vertex?
Ya that’s a very insightful question. I regret not explaining that in more detail now in hindsight. Sometimes in shaders it’s really useful to have the world position of the model before it’s projected into perspective. This can be used for a variety of rendering techniques.
So in a shader you will commonly have
WorldPosition = modelTransform * vertexPostion;
Then do some stuff with worldPostion
Then finally
gl_Position = projectionMatrix * worldPosition;
If you precombine the two matrices you wouldn’t be able to get the world position. I also haven’t explained the viewingMatrix for apply the camera transform but sometimes you want to do stuff within the vertex shader using the position after applying the camera transform as well.
Cool Video
Quality content. I want to use an offline renderer based on your design for my future videos.
That would be cool! and thank you :)
Hi,I was a bit bugged by the resizing of the window and how the cube is resized with it.
In the "Viewport transform and the aspect ratio" part as well as the last part I'm not sure if you really wanted the behaviour you got. I specifically mean minute 6:54 or 8:13, where you demonstrate how the cube would be represented with an aspect ratio lower than 1.
For the first part, when we call "camera.setOrthographicProjection(-aspect, aspect, -1, 1, -1, 1)" I checked if the aspect ratio was lower than 1, in which case I called "camera.setOrthographicProjection(-1, 1, -1/aspect, 1/aspect, -1, 1)", resulting in the cube getting smaller instead of remaining the same size when resizing the window with a lower width than height.
In the same way I modified the "setPerspectiveProjection()" function to consider have an orthographic view volume of at least [left=-1, right=1, top=-1, bottom=1, near=-1, far=1], resulting in:
void LveCamera::setPerspectiveProjection(float fovy, float aspect, float near, float far) {
assert(glm::abs(aspect - std::numeric_limits::epsilon()) > 0.0f);
auto aspect_nominator = aspect;
auto aspect_denominator = 1.0f;
if (aspect < 1.0f) {
aspect_nominator = 1.0f;
aspect_denominator = 1 / aspect;
}
const float tanHalfFovy = tan(fovy / 2.f);
projectionMatrix = glm::mat4{0.0f};
projectionMatrix[0][0] = 1.f / (aspect_nominator * tanHalfFovy);
projectionMatrix[1][1] = 1.f / (aspect_denominator * tanHalfFovy);
projectionMatrix[2][2] = far / (far - near);
projectionMatrix[2][3] = 1.f;
projectionMatrix[3][2] = -(far * near) / (far - near);
}
aspect_nominator is the given aspect ratio. But when this is smaller than 1, we must scale it from the width.
Yes this is a good point! Your solution will avoid ever having parts of the view that we want displayed from being cut off as mine does when the height > width
Just wondering why you aren't using glm::ortho and glm::perspective for these? Is it just for learning?
Yup! Also glm is built for openGL which uses a left handed coordinate system and different conventions for the view direction. So using the glm methods results in the y axis getting flipped upside down.
If you're making an engine that can run with either openGL and vulkan then using the glm functions makes sense, and in the case of vulkan you can correct the y with gl_Position.y = -gl_Position.y in your vulkan shaders.
But since we're doing exclusively Vulkan it made more sense to create our own matrix functions specific to the coordinate system and view direction conventions we are using.
For more info see: matthewwellings.com/blog/the-new-vulkan-coordinate-system/
My friends, search for your life purpose, why are we here?? I advise you to watch this series and this video 👇 as a beginning to know the purpose of your existence in this life ua-cam.com/play/PLPqH38Ki1fy3EB-8xmShVqpbQw99Do2B-.html
ua-cam.com/video/7d16CpWp-ok/v-deo.html
Any good tutorials on how to install/use the GLM library? Got 2 minutes in a walled at the #include part.
@Brendan Galea My app quits without throwing an exception after trying to resize it. Am I missing something? (win10/visual studio 2019 community)
hmmm is a segfault occuring? You could try running in debug mode with gdb which would isolate the exact location the crash occurs. Alternatively join the dicord discord.gg/CUQkuKsszr and post in debugging help. Myself or someone else is usually quick to lend a hand :)
My friends, search for your life purpose, why are we here?? I advise you to watch this series and this video 👇 as a beginning to know the purpose of your existence in this life ua-cam.com/play/PLPqH38Ki1fy3EB-8xmShVqpbQw99Do2B-.html
ua-cam.com/video/7d16CpWp-ok/v-deo.html
Could you please add rendering during resizing?
I guess the lags are created because the window resize callback is called constantly, but how do you fix rendering during that time?
The lags are caused by glfw. Essentially when we call glfw poll events the function call blocks while resizing occurs. There are a couple ways around it but the best way is to use multiple threads with one thread always rendering but it adds some other complexity.
It’s something I want to do eventually but for the beginner content I’d like to stick with just using one thread.
Ok, thanks a lot. Lets hope that this series will continue into an advanced one :D