I am trying to generate some new IBL environments using glTF-IBL-Sampler (because the KTX2 textures in glTF-Sample-Environments won’t load with the latest KTX-Software/libktx as they appear to be an outdated format). I can get this to work, I compiled the source myself and the results look great.
However I have one question. My shaders are mostly just slight modifications of the shaders in the glTF-Sample-Viewer and there is one LUT texture that I am basically just pulling from the sample viewer repo because I don’t know how to generate it myself.
The IBL Sampler will generate the other two but not this one.
Can someone tell me how this Sheen E LUT was generated?
Also, are the GGX/Charlie LUTs generated by the IBL sampler always the same? The fact that they are output params seems to imply that they may be dependent on the HDR file provided but they always look the same to me.
So I had noticed this shader before and looked through the ibl-sampler.js that the sample viewer is using. Correct me if I am wrong, but it looks like the sample viewer is generating the cubemaps/LUTs at runtime from HDR files. In my case I am prefiltering the IBL cubemaps and loading them directly from .ktx2 files using the libktx wasm. Then passing those to the shader and all works.
However my confusion is mainly around the Sheen (E) LUT, used by the material-info shader. The ibl-sampler.js and the shader you have referenced doesn’t generate this one either. It seems to always pull it from the file:
And it’s only used when punctual lighting is used:
The KHR_lights_punctual extension doesn’t mention this anywhere. I haven’t read through all of the linked theory documents in the shaders but I did try to find a reference to this Sheen E LUT and I can’t find it anywhere. There is a lot so maybe I just missed it. I don’t even know what the E stands for so it’s difficult to search for.
Any insights to point me in the right direction would be much appreciated.
My intention is to only use this approach until the KHR_lights_environment extension is ratified. I do hope that the glTF-IBL-Sampler project is revisited, because it is nice from a renderer developer perspective to not have to deal with this at runtime. Prefiltering and loading them from ktx2 files was pretty straightforward (with the exception of my confusion here of course). FWIW, The only change I made to the project when I compiled it was use the latest KTX-Softwarev4.0.0 branch. Before this change (and when using the current ktx2 files in the glTF-Sample-Environments) resulted in a “Texture type not supported” error.