Khronos Public Bugzilla
Bug 1337 - Artefacts during volume rendering - texture lookup problem?
Summary: Artefacts during volume rendering - texture lookup problem?
Status: NEW
Alias: None
Product: WebGL
Classification: Unclassified
Component: WG Issue Tracking (show other bugs)
Version: 1.0
Hardware: Macintosh Mac OS
: P3 normal
Target Milestone: ---
Assignee: 3dweb Working Group email alias
QA Contact:
Depends on:
Reported: 2015-05-01 03:14 PDT by niall.robinson
Modified: 2015-05-14 13:31 PDT (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description niall.robinson 2015-05-01 03:14:48 PDT
I've noticed artefacts when implementing volume rendering which seem to be OS dependent.

Example website:

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:

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).
Comment 1 Kenneth Russell 2015-05-01 16:01:31 PDT
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.
Comment 2 niall.robinson 2015-05-08 07:06:12 PDT
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?
Comment 3 niall.robinson 2015-05-08 07:42:54 PDT
Even more specifically - it seems that its the mipmapping in the texture lookup which causes the artefacts
Comment 4 Olli Etuaho 2015-05-08 08:25:45 PDT
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.
Comment 5 niall.robinson 2015-05-10 08:43:52 PDT
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?
Comment 6 niall.robinson 2015-05-14 03:53:42 PDT
Hi everyone - is this in a fit state to be logged as bug now? Do you need more information from me?
Comment 7 Kenneth Russell 2015-05-14 13:31:31 PDT
@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.