Khronos public bugtracker – Bug 1337
Artefacts during volume rendering - texture lookup problem?
Last modified: 2015-05-14 13:31:31 PDT
I've noticed artefacts when implementing volume rendering which seem to be OS dependent.
Example website: http://www.lebarba.com/WebGL/Index.html
On some OSs (OSX definitely, I think also Linux), this website (and similar implementations) has an artefact where the side of the rendered volume is opaque.
Stack Overflow post with images: http://stackoverflow.com/questions/29493673/hazy-artefact-on-os-x-webgl-on-sides-of-volume-rendering
My setup, which produces the artefact: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36.
Also happens if I use Firefox 37.0.2
This also seems to happen on Linux, but does not seem to happen on Windows machines (although I don't have a test machines to give you specific settings).
I can confirm that the rendering artifact shows up on Mac OS and Linux, and doesn't on Windows. Given that, you're probably running into a behavioral difference between an OpenGL implementation and ANGLE, which implements OpenGL ES on top of Direct3D, and which Chrome and Firefox use on Windows to implement WebGL.
Please work to create a reduced test case from your application. We'd like to understand where the difference is and add a conformance test for it.
I think we've cornered this behaviour more. All artefacts (hazy sides, concentric rings, and separately visible layers) disappear when we switch from interpolation to nearest neighbour sampling i.e. by adding this line
texture.minFilter = THREE.NearestFilter;
to our THREE.js code. I hope this helps point to the bug more specifically.
Incidentally, this drastically slows down the rendering, which we found very surprising. Isn't the shader doing far fewer texture lookups now?
Even more specifically - it seems that its the mipmapping in the texture lookup which causes the artefacts
Is the mipmapped texture being sampled inside non-uniform control flow (typically inside an if statement?). That has undefined results in ESSL, see ESSL 1.00 spec appendix A6. That might be behind your troubles, can you confirm whether this is the case?
If this is behind the issue, and hoisting texture sampling outside of if statements is not practical in your case, you might get better results also by using texture2DLod to specify lod manually.
Hi Olli - thanks for the input. As it happened, I was doing that - and I hadn't realised it was a problem. However, it was trivial to remove, which I have now done. This hasn't sorted the artefacts.
Also, the live example that I linked to, Lebarba, doesn't have any texture2D calls inside conditional statements
Would this issue be OS (I guess that means OpenGL/ANGLE) dependent?
Hi everyone - is this in a fit state to be logged as bug now? Do you need more information from me?
@niall.robinson: we really need you to create a minimized test case -- one which draws only a couple of triangles and has a shader which demonstrates a difference in rendering between Linux and Windows. You can iteratively delete code from your shader, replacing computations with constant values, until you've got the minimal shader which shows the difference.
We receive a lot of issue reports, and it isn't feasible for us to do this process for each one.
We appreciate your help with this. We would like to understand what's going on here and write a WebGL conformance test ensuring that this behaves identically on all platforms in the future.