While playing around with the new Scene.background feature, I stumbled upon a weird clipping issue that can be observed under certain circumstances.
In this jsFiddle, I reproduce the issue by purposely setting the viewport height to a very small value. The following screenshot shows the resulting problem:

_The skybox is occasionally being clipped in an unexpected way._
This behaviour can also be observed in this example from #9158. If you decrease the browser height enough you'll notice the same issue while moving the camera.
I don't know what causes this issue, but - at least in the jsFiddle - it disappears after disabling the logarithmicDepthBuffer.
[x] 79dev
[ ] All of them
[ ] Internet Explorer (11)
[ ] All of them
Only tested on Windows.
I can reproduce on OSX too. Any ideas @jbaicoianu?
Hmm, I'm not that familiar with the env map shader, but I would guess that we need to apply the logarithmic depth transform to the world position when we pass it to the env map shader here
https://github.com/mrdoob/three.js/blob/master/src/renderers/shaders/ShaderChunk/envmap_vertex.glsl#L3-L9
Specifically, this transform: https://github.com/mrdoob/three.js/blob/master/src/renderers/shaders/ShaderChunk/logdepthbuf_vertex.glsl#L3 (and maybe line 11 as well)
Actually, the problem is in the background. Which uses these shaders:
https://github.com/mrdoob/three.js/blob/master/src/renderers/shaders/ShaderLib/cube_vert.glsl
https://github.com/mrdoob/three.js/blob/master/src/renderers/shaders/ShaderLib/cube_frag.glsl
This behaviour can also be observed in this example from #9158. If you decrease the browser height enough you'll notice the same issue while moving the camera.

Oh, that's a different problem (that example doesn't use logarithmicDepth). But it sure is a problem...
Hmm, actually now that I think about it some more, I believe I was wrong about applying the depth transform to the world position, in either env map or the cube shader - the logarithmic depth buffer code works in screen space, so transforming the world position in the same way doesn't make sense.
What about the clipping plane code, is there a chance this is related or is that not used unless explicitly enabled?
Hmm, actually now that I think about it some more, I believe I was wrong about applying the depth transform to the world position, in either env map or the cube shader - the logarithmic depth buffer code works in screen space, so transforming the world position in the same way doesn't make sense.
Uh oh!
What about the clipping plane code, is there a chance this is related or is that not used unless explicitly enabled?
The scene doesn't have any clipping planes, so I don't think it's the case.
This is proving difficult to debug - I tried to inspect the generated material using WebGL Inspector, but when using WebGL Inspector the problem goes away. I'm trying to verify whether the EXT_frag_depth extension is being used or not. Logarithmic depth buffer without gl_FragDepth has problems with very large triangles (eg, ones which fill the whole screen) which might lead to this sort of problem.
Maybe a simple solution would be to tessellate the cube a bit? 馃槄
I didn't want to suggest it because it feels like cheating, but it's worth a try to see if my theory is correct. :grinning: Where is the geometry for the background cube generated?
Confirmed, increasing tesselation helps. 4 segments and the problem completely disappears in the example.
I'm going to try some tweaks to the shader to see if I can fix it there first, but if those fixes don't work then at least we have a plan B. I'll open a pull request either way.
I'm going to try some tweaks to the shader to see if I can fix it there first, but if those fixes don't work then at least we have a plan B. I'll open a pull request either way.
Great! Let us know if you find something.
The shader fixes turned out to be a bust, there were a couple variations in the original articles I followed for this implementation, but they didn't seem to fix the problem. The solution in the pull request increases tesselation for the background cube, but only when logarithmicDepthBuffer is enabled and supported.
For reference, these three blog posts cover the theory and implementation:
http://outerra.blogspot.com/2009/08/logarithmic-z-buffer.html
http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html
http://outerra.blogspot.com/2013/07/logarithmic-depth-buffer-optimizations.html
I didn't want to suggest it because it feels like cheating
I also think that the current workaround shouldn't be considered a permanent solution.
It's strange that there have never been any clipping issues with the old approach (jsFiddle) and now with Scene.background it broke all of a sudden.
But then again, it's already strange enough that the problem does go away when logarithmic depth is disabled :confounded:
It may be that the background code is executed prematurely (before the extension is executed). I'll investigate...
Thanks a lot for the jsfiddle using the previous approach!
Seems to be an issue with the size of the cube being used for the background. It's difficult to have a size that works in all scenes...
Actually, I wonder if we even need compute the logarithmic depth buffer in the cube shader. The camera is supposed to be always in the center...
Fixed! https://jsfiddle.net/cdd2a3db/6/ 馃榿
Nice! :tada:
Even better, great!