Seems like the blur algo for a slightly rought material with transmission is not very smooth. Is there a way to fix it?
Here’s what I mean, see when I move the camera that the blur effect of the transmitted environment is thatchy, rather than all the way smooth:
The “blur” is based on forcing using a lower res mipmap afaik, which is very good for realtime performance, a bit less for quality.
Roughness values closer to 0 or 1 tend to look smoother than those in the middle of the range. Resolution of the transmission render target is not currently configurable, so at the moment there is no other workaround.
I think we should provide options. Default can be a faster blur, but there can be a better looking one too.
UIs nowadays have perfect-looking blur that runs perfectly well on mobile phones, so I think we should provide a better blur option in these times.
iOS UI has had smooth (fast) blur for a long time, for example:
I saw a thread with a nice fast (good) blur somewhere…
Collecting some resources for reference:
A single-pass gaussian blur: Shader - Shadertoy BETA
This one seems to blur in both directions really fast, great results, 140+ fps on all settings on my laptop full screen:
I think the current implementation is using mipmaps, not a blur pass. Refraction isn’t uniform, roughness information might be coming from a texture, and mipmaps allow us more easily to work with variable roughness. The easier option to expose might be resolution of the render target. Or WebGL 2 also has some useful options here that aren’t integrated yet, and could match resolution to the viewport perhaps. Some more details in:
Improve MeshPhysicalMaterial transmission support by takahirox · Pull Request #21884 · mrdoob/three.js · GitHub
Would be curious about results with gaussian blur, but I suspect it might get pretty expensive when used in this context.
Even if the shader is fast, the additional render pass itself will introduce an overhead that will make the entire solution noticeably less performant. We have lately measured the same effect when trying to perform sRGB conversion and tone mapping not inline but with post processing.
Avoiding additional render passes and using alternative approaches (like mipmaps for blur or doing stuff inline) is the more appropriate default.