In the `directionToSphericalEnvmap` and `sphericalEnvmapToDirection` functions, used z axis as up direction. But in OpenGL, y axis is up direction. Do we need to swap the y and z axes？
Yes, the y-axis points up in the OpenGL camera coordinate system. However, you can set the orientation of the environment map to any direction in the global coordinate system of the scene, which is what we did here.
PDF acts as weights for corresponding values of angles. So shouldn't it be multiplied? Wouldn't dividing weigh low probable values more in expected value computation? What am I missing here?
I see what you mean. You are referring to the slide about importance sampling at 3:53 min:sec. But this is different from computing the expected value of a random variable. We approximate an integral by sampling. At locations where the PDF is high, we sample more densely but each sample is weighted less. This makes perfect sense, as I have tried to illustrate with the green rectangles that approximate the area under the function. If the PDF is high and we sample more densely, the rectangles have a smaller width. Thus, we approximate the true area under the function more closely at those locations. This is also the reason why the theory of importance sampling tells us that the PDF should be high if the function values are high. Because otherwise, we get larger approximation errors at locations where the function values are high. Another way to think about it: Imagine the width of the rectangles would not be smaller for locations where the PDF is high. Because we sample more often at those locations, the area contribution of those samples would be too large.
Awesome series! I expect your channel will thrive. Generating C/C++ code which previously had to be hand written by GLSL "specialists" makes these specialists look a lot more like accountants - follow the recepie, and you found the recepie. Now I'm thinking about the way you explained how to implement the fragment shader and hand coded it - deja-vu? Could more nodes in GSN Composer allow the fragment shader to be generated? Maybe not - it could end up being more like scratch. I'm trying to use shaders to do Qt6 image processing and your channel has reduced my effort from months to days - thank you. Generating Qt6 C++ would be greatly appreciated. Otherwise if there's a GLSL -> Qt6 converter resource you know of, please let me know. I take it that your channel is part of a university program, in which case I hope this public facing approach will prevail - free knowledge, and we'll need that moving forward. I can't believe the Khronos group haven't done this already to open up the prospect of increasing GLSL proficiency to the wider public.
Thanks for your thoughts and feedback. Yes, exactly, the GSN Composer is not a node-based shader code generator. Instead, its node-based interface serves as a rapid prototyping environment to feed the shader’s uniform variables. This allows teaching shader programming with real GLSL code (but without the boilerplate C++ code). If you are doing image processing in the shader, remember to implement it as a separable filter whenever possible. The videos are intended as an additional learning resource for a lecture at the University of Marburg: www.uni-marburg.de/en/fb12/research-groups/grafikmultimedia/lectures/graphics You can find QT C++ examples on this website. But I will add a QT C++ export option to the shader editor of the GSN Composer in the next few days.
I have added the option to export to Qt6 C++ in GSN Composer Version 0.8.15. Maybe you need to reload the website with "Ctrl + Reload" to force the browser to ignore the cached version.
![Importance Sampling: Image-based Lighting of a Lambertian Diffuse BRDF [Shaders Monthly #10]](/img/logo.svg){kind=logo}
