v1.10 Darker models on some devices

[lucadalli]

Description

Models on my Xiaomi Mi 9T appear darker on v1.10 than they did on v1.9 and previous versions. Might be irrelevant but the material on the model shown below has a base color factor of #cccccc. Even with a factor of #ffffff there is a difference but it is not as pronounced.

v1.10	v1.9

Live Demo

http://modelviewer-tester.glitch.me/
Attached below are screenshots demonstrating the astronaut on v1.10 and v1.9. The difference is not as evident as the models above but still present.

v1.10	v1.9

Version

• model-viewer: v1.10.1

Browser Affected

• Chrome, version: 97.0.4692.98
• Edge
• Firefox
• IE
• Safari

OS

• Android
• iOS
• Linux
• MacOS
• Windows

AR

• WebXR
• SceneViewer
• QuickLook

[samaneh-kazemi]

Hi @lucadalli, thanks for reaching out. This is intentional. As of #3082 pr, we switched from gamma encoding to sRGB and that's causing the change. You should be able to get similar results to before by playing with exposure.

[lucadalli]

@samaneh-kazemi The release notes state that the intended behavior is for the models to appear lighter not darker with v1.10.
In fact, on my Windows machine models appear ever so slightly lighter, as expected. On the Xiaomi Mi 9T, models appear considerably darker (kindly revisit the screenshots above and pay a closer look to the version labels).
It's intentional that models appear slightly lighter on some devices and considerably darker on others?

[lucadalli]

Here's a comparison demonstrating the inconsistency between the two devices.
Observe how version v1.9 (right) appears the same on both devices, and v1.10 is slightly lighter on the Windows machine but darker on the Xiaomi Mi 9T.

Windows v1.10	Windows v1.9

Xiaomi Mi 9T v1.10	Xiaomi Mi 9T v1.9

[elalish]

Now that is quite interesting! @mrdoob do you have any idea why the Xiaomi would be darker now on r136? I assume this is from changing gammaEncoding to sRGBEncoding which I did as part of the upgrade. Do you think this is some kind of driver bug, or maybe they just don't support sRGB? Have you noticed this on any of your devices?

[mrdoob]

My devices are still in storage in San Francisco 😢

@lucadalli could you check if your device supports WebGL 2.0? https://webglreport.com/?v=2

[lucadalli]

@mrdoob

[elalish]

@Mugen87 Do you happen to have any devices that repro this? It seems like some kind of sRGB driver problem? I haven't managed to repro.

[Mugen87]

I have compared v1.10 with v1.9 on three devices so far (iMac, Windows Laptop and Pixel4a) and all render as expected.

@lucadalli It seems you have only tested with Chrome on your Xiaomi Mi 9T. Can you please make a test with a different browser like Firefox? If the behavior is the same, it indeed indicates a driver issue.

For clarity, sRGB encoded textures used to darken in three.js which was wrong. Since r136 the related sRGB workflow is implemented differently by using SRGB8_ALPHA8 which fixed this issue. So depending on the texture filtering settings, textures appear lighter which just means they do no wrongly darken anymore (the brightness is now constant).

[Mugen87]

For better testing here are two fiddles with plain three.js:

r132 (❌): https://jsfiddle.net/sj50nrw4/1/
r138 (✅): https://jsfiddle.net/jtmnd9x4/

With r132 textures should get slightly darker from left to right. With r138, brightness keeps constant.

If Chrome does not render like described on a device, I suggest to file a bug at the Chromium bug tracker.