@Unity Programmer Yeah I guess most beginner level OpenGL tutorials and books have to go through a very similar path at this stage but I believe there will be unique material in the future so stay tuned!
The series has been awesome. Just want to add a note for 6:19, we use reverse vector as we know that the angle of reflection vector wrt normal will be same as the angle of light vector. This only clicked me after you explained reflect function
Thanks! I think that the most intuitive example is that when the light vector is perpendicular to the surface. In that case the light vector and the normal are directly opposite so in theory the angle between them is 180 degrees but of course we want to refer to this case as if the angle is zero so we reverse the light vector. Some people prefer doing the reverse already in the application so save them from this operation in the shader on every pixel. This makes sense but for educational reasons I do it all in one place.
At 11:30 and in your other videos (like for directional lighting), you bring up transforming everything back to local space from world space. However you mentioned that this would only work for uniform scaling, and that your solution of transposing the matrix is just a temporary one. It's a little scary for me to leave it that way, since you haven't brought this back up and clarified the proper way to do it which would handle non-uniform scaling. I think having non-uniform scaling is important and so my question is, how would I properly transform to local space? The code in question is the DirectionalLight local space direction calculation, and the WorldTrans WorldToLocal(). For the DirectionalLight, is it as simple as inverting the mesh's world transform matrix4x4, rather than transposing the top-left matrix3x3? You mentioned inverting it at 11:59. I already can invert it but am not sure if it's the correct solution, or whether to invert just the 3x3 portion or the entire 4x4 portion and skip the second vector multiplication. As for the WorldTrans one, I'm not sure if it needs updating since it's only used for the camera's local position and point lights' local positions, and we calculate their directions in the fragment shader with a simple subtraction. I figured I'd ask in case you could give me an answer for both since it's a little unclear for me right now, even though I think I understand how it all works Also thank you for your resources, I am grateful, and that you also take the time to reply to comments, you are invaluable
Thanks for bringing up the issue of scaling because there is a problem there and I wanted to do a followup video about it but couldn't find a time to squeeze it into the agenda. The problem is mostly for point lights where the vector to the light source changes from pixel to pixel. Let's say that you have a normalized quad from (-1,0,-1) to (1,0,1) and you want to use it as a large field and run a point light along it (see the point light demo on my website). With these coordinates you just need to apply a large scaling factor so no rotation and translation whatsoever. The light source local position is equal to its world position in this case. As the light runs back and forth along the field you expect it to attenuate and be visible only locally. In addition, the vector from the light to the far end of the field should be very sharp, affecting the diffuse factor. But if you ignore scaling you will do all calculation on the original (small) quad and it wil not be as expected. If you’re using uniform scaling the solution is simply to provide the scaling factor as a scalar to the VS and multiply it by the local position. It’s still less expensive than multiplying by a matrix. In the case of non-uniform scaling you can supply a vector of scaling factors and multiply it by the local position. GLSL does component wise multiplication in this case which is exactly what we need. Regarding WorldToLocal: in the case of diffuse lighting we just need to reverse the rotation so transposing the top 3x3 matrix should be enough. Translation won’t affect the light vector so we can ignore it. In the case of specular lighting we reverse translation and rotation separately and combine them to get the inverse. I agree that this is somewhat cumbersome so if you want to use a simple inversion of the entire matrix (using the determinant, etc) in the 4x4 case go ahead.
@@OGLDEV Yep, I ran into that point light scaling issue in my test scene, where the light was stretching with the entire mesh, because as you said, it was using the original small mesh as a reference. However I decided that I will tackle this local space optimization another time, since it's adding a bit more complexity than I'd like at the moment. I want to get things as robust as possible for the future before I start optimizing my systems, but I was curious about it so I figured I'd ask you, and you explain everything perfectly. I look forward to your next videos even though I started learning all of these things last year, because you keep teaching me advanced things that other teachers are leaving out, like these local transformation optimizations. So once again, thank you for all you do :)
Don't miss the previous tutorial on ambient lighting! - th-cam.com/video/YnBhJbQZLuE/w-d-xo.html
@Unity Programmer Yeah I guess most beginner level OpenGL tutorials and books have to go through a very similar path at this stage but I believe there will be unique material in the future so stay tuned!
@Unity Programmer Ogre3D supports both APIs as backends but do you need direct access to the gpu? Not sure how simple that is.
keep working on this tutorials extremely helpful!
Sure will, thanks!
The series has been awesome.
Just want to add a note for 6:19, we use reverse vector as we know that the angle of reflection vector wrt normal will be same as the angle of light vector. This only clicked me after you explained reflect function
Thanks!
I think that the most intuitive example is that when the light vector is perpendicular to the surface. In that case the light vector and the normal are directly opposite so in theory the angle between them is 180 degrees but of course we want to refer to this case as if the angle is zero so we reverse the light vector. Some people prefer doing the reverse already in the application so save them from this operation in the shader on every pixel. This makes sense but for educational reasons I do it all in one place.
Keep up the awesome work!
Thank you!
At 11:30 and in your other videos (like for directional lighting), you bring up transforming everything back to local space from world space. However you mentioned that this would only work for uniform scaling, and that your solution of transposing the matrix is just a temporary one. It's a little scary for me to leave it that way, since you haven't brought this back up and clarified the proper way to do it which would handle non-uniform scaling. I think having non-uniform scaling is important and so my question is, how would I properly transform to local space?
The code in question is the DirectionalLight local space direction calculation, and the WorldTrans WorldToLocal(). For the DirectionalLight, is it as simple as inverting the mesh's world transform matrix4x4, rather than transposing the top-left matrix3x3? You mentioned inverting it at 11:59. I already can invert it but am not sure if it's the correct solution, or whether to invert just the 3x3 portion or the entire 4x4 portion and skip the second vector multiplication. As for the WorldTrans one, I'm not sure if it needs updating since it's only used for the camera's local position and point lights' local positions, and we calculate their directions in the fragment shader with a simple subtraction. I figured I'd ask in case you could give me an answer for both since it's a little unclear for me right now, even though I think I understand how it all works
Also thank you for your resources, I am grateful, and that you also take the time to reply to comments, you are invaluable
Thanks for bringing up the issue of scaling because there is a problem there and I wanted to do a followup video about it but couldn't find a time to squeeze it into the agenda. The problem is mostly for point lights where the vector to the light source changes from pixel to pixel. Let's say that you have a normalized quad from (-1,0,-1) to (1,0,1) and you want to use it as a large field and run a point light along it (see the point light demo on my website). With these coordinates you just need to apply a large scaling factor so no rotation and translation whatsoever. The light source local position is equal to its world position in this case. As the light runs back and forth along the field you expect it to attenuate and be visible only locally. In addition, the vector from the light to the far end of the field should be very sharp, affecting the diffuse factor. But if you ignore scaling you will do all calculation on the original (small) quad and it wil not be as expected. If you’re using uniform scaling the solution is simply to provide the scaling factor as a scalar to the VS and multiply it by the local position. It’s still less expensive than multiplying by a matrix. In the case of non-uniform scaling you can supply a vector of scaling factors and multiply it by the local position. GLSL does component wise multiplication in this case which is exactly what we need.
Regarding WorldToLocal: in the case of diffuse lighting we just need to reverse the rotation so transposing the top 3x3 matrix should be enough. Translation won’t affect the light vector so we can ignore it. In the case of specular lighting we reverse translation and rotation separately and combine them to get the inverse. I agree that this is somewhat cumbersome so if you want to use a simple inversion of the entire matrix (using the determinant, etc) in the 4x4 case go ahead.
@@OGLDEV Yep, I ran into that point light scaling issue in my test scene, where the light was stretching with the entire mesh, because as you said, it was using the original small mesh as a reference. However I decided that I will tackle this local space optimization another time, since it's adding a bit more complexity than I'd like at the moment. I want to get things as robust as possible for the future before I start optimizing my systems, but I was curious about it so I figured I'd ask you, and you explain everything perfectly.
I look forward to your next videos even though I started learning all of these things last year, because you keep teaching me advanced things that other teachers are leaving out, like these local transformation optimizations. So once again, thank you for all you do :)