Very cool! I have a question though, wouldn't the Reverse face-culling solution fail if i had a non-closed mesh? I.e. a plane mesh acting as a "wall". Let's say i place perpendicular to the ground, if i understand the solution correctly, it should fail to produce shadows since there won't be any back facing triangles
As someone said in another comment, how do you fix the small gap between, for example, the ground and an object on top of it? I've set my bias to zero and there still a tiny but noticeable sliver of "unshadowed" area where an object touches the ground.
Jus to clarify, I'm using reverse face culling, but it still happens when the object on top of the ground has no "flooring" (that is, has no faces on it's underside). Is the fix just making sure all objects have faces under them, or is there another way?
Is the object very thin? The recommendation is to avoid thin geometry when there is a problem of peter panning. Reverse face culling is usually the solution and if you can enable that by having flooring on your objects then that effort is certainly worthwhile.
Do you have a plan to explain the CSM in your tutorial, I can read the blog on your website. I implemented CSM according to LearnOpenGL but I found that the shadow acne is really trick to overcome.
I'm using reverse face culling for rendering shadows, but there is tiny gap on the border between the object and its shadow. How to solve this issue? Is PCF a possible solution?
Wow total shadow tech video is very good!! I have two question. first flexible bias equation is not consider texSize and not linear so i think it was to be "bias = sin(acos(NDL))*texSize" is it right?? but this equation may be heavy.. :( second your coord and vector plot in blue slide is very efficient to read can i get a name of program for make this?
Thanks! Not sure I understand the equation with texSize. Perhaps you can share more details. Regarding the second equestion - I usually create my slides using Google docs. Which specific blue slide are you referring to?
What's the point of calculating the first AABB without translation in the light space matrix if we are just going to end up reverting it back into world space then back to light space with translation and use the AABB based on that. edit: oh, we get the center of the first AABB, then calculate the world position of that, and then transform that using light space matrix with translation.
Exactly, we want to "stick" the light on the center of one of the sides of the bounding box. It's easier to calculate the bounding box in light space so the first transformation to light space is without translation. This keeps it in the same location. The second transformation includes translation to move it back to the origin. I'm pretty sure you can calculate it with less steps but I suspect the calculation itself will be more complex. This calculation is "lazy" in the sense that the frustum and bounding box are calculated each in the coordinate system where it is easiest to do so. This incurs a few coordinate system transformations using the tools that we already have.
For the tight-fitting light-projection, I feel like I completely understand each component 110%, but putting it all together it's just not anywhere close to working. Does my world space up-axis matter at all? That's the only difference from my code and yours, but I don't think it would make a difference. Also instead of doing tan to find the frustum planes I'm using the inverse projection matrix, maybe that's the issue too.
Are you on a right or left handed coordinate system? Sometimes this is the reason why people need to tweak my code a bit to make it work for them (I'm using the left handed system). If you're following the same steps you should be able to compare intermediate results between your code and mine. And of course if you know that you've changed something fundamental try to use the original version to pinpoint the problem.
@@OGLDEV Ahh, yes, I changed the code to find the midpoint on the max-Z plane rather than the min-Z plane, and that seems to have worked. Viewing the light-space through the camera's MVP helped. Thanks for your response, and the tutorial!
More than happy to support you on Patreon! This is wonderful content, thank you!
Wow, thank you! Welcome to the OpenGL underground!
I appreciate your effort to make these tutorials, thank you
My pleasure!
I love this series
Thank you :-)
Hello Mr. Feynman! :]
Very cool! I have a question though, wouldn't the Reverse face-culling solution fail if i had a non-closed mesh? I.e. a plane mesh acting as a "wall". Let's say i place perpendicular to the ground, if i understand the solution correctly, it should fail to produce shadows since there won't be any back facing triangles
Correct. With front face culling you need back faces to render into the shadow map.
As someone said in another comment, how do you fix the small gap between, for example, the ground and an object on top of it? I've set my bias to zero and there still a tiny but noticeable sliver of "unshadowed" area where an object touches the ground.
Jus to clarify, I'm using reverse face culling, but it still happens when the object on top of the ground has no "flooring" (that is, has no faces on it's underside). Is the fix just making sure all objects have faces under them, or is there another way?
Is the object very thin? The recommendation is to avoid thin geometry when there is a problem of peter panning. Reverse face culling is usually the solution and if you can enable that by having flooring on your objects then that effort is certainly worthwhile.
Very informative. Thanks for article links.
Glad it was helpful :-)
Do you have a plan to explain the CSM in your tutorial, I can read the blog on your website. I implemented CSM according to LearnOpenGL but I found that the shadow acne is really trick to overcome.
In general yes, though it's not on the immediate roadmap so not sure I'll be able to make it this year.
@@OGLDEV Thank you for your reply. Looking forward to the upcoming video.
I'm using reverse face culling for rendering shadows, but there is tiny gap on the border between the object and its shadow. How to solve this issue? Is PCF a possible solution?
Sounds like a bias issue.
@@OGLDEV What if this still happens with the bias set to zero?
Wow total shadow tech video is very good!! I have two question. first flexible bias equation is not consider texSize and not linear so i think it was to be "bias = sin(acos(NDL))*texSize" is it right?? but this equation may be heavy.. :( second your coord and vector plot in blue slide is very efficient to read can i get a name of program for make this?
Thanks! Not sure I understand the equation with texSize. Perhaps you can share more details. Regarding the second equestion - I usually create my slides using Google docs. Which specific blue slide are you referring to?
Oh no I have to fix my shadows now, thanks tho!
LOL :-)
What's the point of calculating the first AABB without translation in the light space matrix if we are just going to end up reverting it back into world space then back to light space with translation and use the AABB based on that.
edit: oh, we get the center of the first AABB, then calculate the world position of that, and then transform that using light space matrix with translation.
Exactly, we want to "stick" the light on the center of one of the sides of the bounding box. It's easier to calculate the bounding box in light space so the first transformation to light space is without translation. This keeps it in the same location. The second transformation includes translation to move it back to the origin. I'm pretty sure you can calculate it with less steps but I suspect the calculation itself will be more complex. This calculation is "lazy" in the sense that the frustum and bounding box are calculated each in the coordinate system where it is easiest to do so. This incurs a few coordinate system transformations using the tools that we already have.
For the tight-fitting light-projection, I feel like I completely understand each component 110%, but putting it all together it's just not anywhere close to working. Does my world space up-axis matter at all? That's the only difference from my code and yours, but I don't think it would make a difference. Also instead of doing tan to find the frustum planes I'm using the inverse projection matrix, maybe that's the issue too.
Are you on a right or left handed coordinate system? Sometimes this is the reason why people need to tweak my code a bit to make it work for them (I'm using the left handed system). If you're following the same steps you should be able to compare intermediate results between your code and mine. And of course if you know that you've changed something fundamental try to use the original version to pinpoint the problem.
@@OGLDEV Ahh, yes, I changed the code to find the midpoint on the max-Z plane rather than the min-Z plane, and that seems to have worked. Viewing the light-space through the camera's MVP helped. Thanks for your response, and the tutorial!
You're welcome :-)
Ahh, finally
:-)
Thank you very much ^^
your videos and your website help me a lot to make my dream come true
You're welcome! I'm very glad to hear that.