WebGLProgram: support cube uv refraction mapping #19623
Conversation
|
It should be clarified (if possible) why this change wasn't done in the first place. Also relevant: #19611 (comment) My guess is that this type of refraction does not play well with PBR models. |
Possibly because our refraction model is inadequate. See the live link above. It is not even reasonably realistic. |
I guess it is relevant to ping @elalish in that case.
Refraction in the rasterizing pipeline is not a solved problem, there's no simple way of rendering refractive materials, especially in a single pass workflow as we are currently using. The model we use is more about what can be done, instead of an approach for realistic refraction. We're only considering the front face surface of the object and simulating refraction only in that surface, but even that is still not completely correct, as we are not assuming a complex index of refraction and the effect of dielectrics ( and all that fun stuff ). It is possible to make it slightly better if we try a multiple depth & normal passes pipeline ( cubemap ) for having a better prediction of how the light being refracted will behave after passing to the interior of the volume. It will look better, but it will still not be photo realistic, simply because it can't be. The interactions of refractive surfaces are way too recursive in nature to be correctly rendered in the rasterizing pipeline.
@mrdoob It does not. They are still considering if that is something they want to venture in for GLTF spec, but it is sitting as "possible" thing. In reality, I don't think it will ever be. With all of that being said, I still think that if a user is requesting support for something that is entirely possible in our current pipeline, even if it is not realistic, and it involves such a simple fix, we have no reason not to support it, for the time being. |
|
To get a better understanding of the parameters I exposed roughness and refractionRatio: demo For me it was just very strange to have that constant, but not the result I was expecting. Sadly the resolution of the PMREM texture is not that high, which is very apparent for refractions. |
This is something I'm looking to tackle soon, I just need to find the time for it. We had discussed previously that allowing the user control of the texture resolution is something that we should probably do. |
|
The only reason I didn't do this in the first place was that I had no refractive models to test with and I didn't want to cause any regressions. I think this is a good idea; it may not be accurate, but it's better than nothing. Kind of like soft shadows; their absence is noticeable, but their accuracy is generally not. As for glTF and refraction, this is actually under very active discussion in the working group. Hopefully before long we will have extensions for a configurable IOR and even a "thickness texture", which kind of like AO, will allow real-time rasterizers to do a halfway decent job of refraction and absorption calculations that would otherwise require raytracing. |
|
Sorry, I have not seen any transparent metals. That is what your example is using. Can you demonstrate that this works when metalness = 0? You may need to test both |
I'm sorry, I copied the example given in the issue, but I did not notice he was applying the refractive envmap to a It appears the refractive mappings in general are only correctly considered when using But this is an issue outside of the scope of this PR, to be honest. This PR just ensures that WebGLProgram correctly understands |
|
Let's see a live demo before considering merging this. |
That is my fault. When I tried to get it working, I used metals, since reflections are way more visible there. Here is the updated example: Demo |
standard_physical_refraction left is standard, right is physical Just to be absolutely clear, this behavior is not exclusive to |
|
After taking a closer look at the results again, there is one inconsistency for me with refraction in the standard and physical material when metalness is set to 0. The fresnel, which makes a lot of sense for reflection does not make any sense (at least I think so) for refraction. I think the result would need to look like metalness 1.0 for refraction, for which you see the pure refraction without any fresnel effect. Of course, going one step further it would be nice to have a fresnel reflection and a pure refraction on the material. Here is the current effect with metalness 0: and this is a changed version with fresnel reflection + refraction with metalness 0: Here is the live example with reflections + refractions: https://rawcdn.githack.com/johannesdeml/three.js/6e57f55b3f3af594dcd23f6fb89ccbfb2dbda5f0/examples/webgl_materials_envmaps.html Not sure if this is a path you want to go, or if you want to wait for gltf to define ior and then implement a general solution. |
sciecode
changed the title
|
Regarding #19623 (comment), is it still desirable to merge this PR? If not, it might be better to remove |
Not sure to be honest, as I mentioned, the refraction map will really only work reliably with metalness = 1.0. Ideally we would want both things to happen for PBR materials, but it is tricky.
|
|
I think incorrect is better than nothing 🤔 |
|
Thanks! |
Fixes #19611
cube_uv_envmaps_example