Three.js: Rendering issue with Intel HD Graphics 620

[silvainSayduck]

Hi,

We have noticed that on computers using Intel HD Graphics chips 620 (or 520), the rendering was completely wrong.
Here are screenshots illustrating the issue, taken from the following link using three.js: https://sayduck.com/3d/jhqw?starting-variant=0od32t8kalqa

On a computer with an Intel HD Graphics 620, the rendering is completely wrong.

And here is the same page on another computer, rendering as it should.

This has been observed on all major browsers (but only on windows 10). Turning off hardware-acceleration for rendering solved the issue, pointing the fault on the GPU chip. The GPU drivers have been updated to the latest version without any impact.
Finally, no errors are present in the browsers' console, and support should be fine for both webGL and webGL2 on the computer (see webGL report files):
WebGL Report.pdf
WebGL2 Report.pdf

Also, the Graphics Feature Status of chrome://gpu has all elements green and "Hardware accelerated" (except for Native GpuMemoryBuffers which is not supported on Windows).

I have filed a report on Intel's community forum too, but thought this might be worth reporting here as well.

Thanks a lot in advance.

---

Three.js version r86
All major browsers
Tested only on Windows 10

[WestLangley]

Unfortunately, your live link is minified and obfuscated, so it is not clear what you are doing to cause this problem.

[silvainSayduck]

Here is a version of the same page where I un-minified the code: https://next.sayduck.com/3d/jhqw?starting-variant=0od32t8kalqa
Hopefully this can help investigating a bit.

[WestLangley]

Well, it is unlikely anyone is going to debug your project. Can you link to a 50-line example that reproduces the problem? Perhaps rendering just a BoxGeometry? That should help you isolate the cause.

[mrdoob]

This has been observed on all major browsers (but only on windows 10).

Sounds like it's a bug in the Intel driver for Windows 10?

[silvainSayduck]

Yes, you are absolutely right. I'll try to setup a simple few-line test case soon. I don't have access to a problematic laptop right now though so it might take some time to get it out.

[silvainSayduck]

So I made a much simpler test code, available here: http://static.sayduck.com/hd_graphics_test/

The correct rendering looks like a rotating cube with metallic reflexion: https://i.imgur.com/EzTaoHX.png
The version on Intel HD Graphics 620 renders like this - basically way too light (or bright): https://i.imgur.com/SbGFsc3.png

[RemusMar]

Sounds like it's a bug in the Intel driver for Windows 10?

More than likely

[silvainSayduck]

Yes, I agree it's very likely. I opened an issue on Intel's Graphics support.

[WestLangley]

First of all, your example is throwing multiple errors in the console.

Second, preserveDrawingBuffer = true is not required to support .toDataURL().

Third, what happens when you remove the environment map? Remove all maps that are irrelevant.

Fourth, an aoMap requires a 2nd set of UVs. You have failed to specify them. Consequently, results will be unpredictable.

Also try the 4 combinations of the 2 args to the WebGLRenderer constructor to see if that is informative.

renderer = new THREE.WebGLRenderer( { antialias: true, alpha: true } );

[silvainSayduck]

Thanks a lot for all the pointers @WestLangley, I'll look into that.

First of all, your example is throwing multiple errors in the console.

I'm not sure what errors you referring to? There are warnings about the change in .texture usage, but those are auto-corrected (at least for now): https://i.imgur.com/FwFFPeQ.png

Third, what happens when you remove the environment map? Remove all maps that are irrelevant.

What do you mean, irrelevant ? the HDR envMap is the one providing the reflections and the light in our setup. As for the other two, they are indeed useless in this dummy example, but it's just to have the same exact material as in the first broken rendering I sent - where the albedoMap and the aoMap are _not_ irrelevant.

[WestLangley]

The purpose of this exercise is not to duplicate your setup. It is to isolate the cause of your problem.

[silvainSayduck]

Fair point.

In the meantime, I got an answer from Intel acknowledging the fact that this is most likely a driver bug - as they could replicate the issue - and that they will investigate.

Thanks again for your help, I assume it is in their hands now.