Android 7.1.2 (LineageOS Guava) does not display colors, all objects are rendered in black

[teodorg]

Description:

On Android 7.1.2 (LineageOS Guava) all objects are displayed in solid black color. Tested with different browsers (Mozilla and Firefox).
Tested on a Motorolla Moto G3. The same device works fine with Android 6 and the problem appears
once it switches to the latest updates of LineageOS 7.1.2.

The problem does not exist on Android 5 and 6.

• A-Frame Version: all
• Platform / Device: Android 7.1.2 (LineageOS Guava) / Motorolla Moto G3
• Reproducible Code Snippet or URL:

[gabrielgrant]

I don't think this is specific LineageOS -- I'm seeing this using Chrome 66.0.3359.158 with LG's stock Android 7.0 (version M21010v; January 1, 2018 security update) with on both my LG Aristo (LG-M210) and my LG Fiesta (LG L63BL)

Edit: Looks like the same issue is reported here: https://stackoverflow.com/questions/48156560/all-shapes-entities-showing-up-as-black-in-a-frame-scenes

[dmarcos]

There must be something specific
to those devices. Do you see any errors on the browser console?

[teodorg]

@gabrielgrant It is not browser specific as well, because I tried with the default Android browser, Firefox and a beta version of Chrome.

@dmarcos It is not specific to the device, because I have two completely identical Motorolla Moto G3 handsets (well, the only difference between them is their color - white and black). One is running LineageOS 7.1.2 and one is running stock Android 6.0.1. The one, equipped with 6.0.1 version renders correctly. The "blacked objects" issue appears only on the LineageOS-equipped handset. Yet, as far as I remember, first my code ran fine on that handset as well and the problem appeared after one of the updates.

[gabrielgrant]

@dmarcos The only errors I see are are two instances of Failed to recalculate device parameters. being logged out

This is coming from here:

Full stack if you're interested:

This seems to be (trying) to load some sort of device parameters from https://dpdb.webvr.rocks/dpdb.json and isn't finding an entry for this device (my device's model number -- LG-M210 -- does not appear in that database). I'm not sure what these parameters are used for, but if this is actually the problem, it seems like this might explain why it is device-specific (though not, afaict, why it would be Android-version specific: the User-Agent string only seems to be matched against device ID).

This DB's info seems to mostly be about display size, though. AFAICS the canvas, at least, seems to be getting set up correctly, so it's totally possible this is a red herring. OTOH it's also possible the black models are coming from some problem with a texture buffer being improperly allocated (perhaps because of this exact missing resolution info).

In either case, I'm a bit out of my depth. Looks like both you and @ngokevin are in the bay area. I'm in SF too and have several of these devices for testing. I'd be happy to get you one of them, or can just supply you with more info if that's easier.

[dmarcos]

It sounds like a problem at the drivers level of your OS + device combo. Something might not be working at the shader level since it works for other OSs versions. Just curious. Is this THREE example rendering correctly: https://threejs.org/docs/scenes/material-browser.html#MeshStandardMaterial

[teodorg]

@dmarcos no, it does not render the graphic object at all.

[dmarcos]

It seems the problem is deep in the guts of the OS / Drivers / Browser / WebGL
implementation. We cannot do much on the A-Frame side. I keep this issue open as a reference and to collect further info.

[gabrielgrant]

Hmmm...it certainly isn't a problem with all WebGL texturing, though -- https://fltr.world/ (simple texture demo implemented with three.js shaders) works fine, as does https://webglsamples.org/aquarium/aquarium.html

As for https://threejs.org/docs/scenes/material-browser.html#MeshStandardMaterial -- it doesn't work with the default settings (colored material), but changing the material to have an emissive color seems to work fine

[dmarcos]

If I have to bet is a problem with the shaders. The shader branch of the MeshStandardMaterial is hitting some bug in the OS / Device / Driver combo you have.

[dmarcos]

@gabrielgrant Would you mind opening an issue on THREE.js too?

[gabrielgrant]

so to clarify: you don't think that device parameter DB issue is related, right?

[gabrielgrant]

@dmarcos Yup, was just in the process of searching their issue tracker for anything related before doing so :)

[dmarcos]

No, I don’t the DB issue is related since also reproduces on THREE.js

[gabrielgrant]

Makes sense, just wanted to confirm

[machenmusik]

if it doesn't ruin the experience, maybe you could try different shader like `flat` as a workaround? (`material="shader:flat"`)

…

On Thu, May 24, 2018 at 1:26 PM, Gabriel Grant ***@***.***> wrote: Makes sense, just wanted to confirm — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3523 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB-_4gbNwwBdNuqiplyeMbpEAR8aTQBfks5t1u1fgaJpZM4TH_DS> .

[gabrielgrant]

Filed here: mrdoob/three.js#14137

[gabrielgrant]

@machenmusik thanks, should have thought of using other non-flat shaders. Tried a few and posted the results here: mrdoob/three.js#14137 (comment)

In particular, MeshLambertMaterial seems like a good alternative. Are all the default three.js materials already registered in A-frame? I only see "standard" and "flat" mentioned on the material page: https://github.com/aframevr/aframe/blob/master/docs/components/material.md (I know this isn't really the appropriate venue for that question, but seems like useful context to have here for people trying to work around this issue)

[machenmusik]

I think only standard and flat are built in at the moment. But @dmarcos @ngokevin @donmccurdy is there any particular reason? Request for Lambert sounds reasonable, for example... And THREE includes all of them either way.

[donmccurdy]

Let's wait and follow mrdoob/three.js#14137. Not opposed to adding Lambert but there hasn't been much need for it, and there may be a simpler solution.

Does material="flatShading: true" (with standard shader, not the flat shader) make any difference here?

[dmarcos]

As don said there has not been much demand for lambert. It would one more code path to maintain.

[gabrielgrant]

Nope:
<a-entity geometry="primitive: box" material="flatShading: true; color: blue"></a-entity> just renders as black

<a-entity geometry="primitive: box" material="shader: flat; color: blue"></a-entity> renders as blue, but (obviously) flat

[dmarcos]

It's a problem with the shader path for the standard material in THREE and your particular combo of device / OS / driver / firmware: 99% sure.

[donmccurdy]

Yeah, I was curious about flatShading because it compiles away one difference between standard and lambert but apparently that wasn't it..

[gabrielgrant]

@dmarcos yes, that certainly sounds like the issue is a problem with the shader using something unsupported. Though if it is, in fact, the same problem as the previously-closed related issue, it doesn't sound particularly specific to any given device: we have repros on 15 different devices from 7 manufacturers, and @EerikKivistik says they "are getting a few hundred reports a week from our users"

My guess is the issue is something to do with the Qualcomm Snapdragon 425/Adreno 308 GPU -- I believe that's the (extremely common) low-/mid-range chip used in most (all?) of the devices reporting this issue (as well as most other common low-/mid-range Android devices available in the market these days)

[gabrielgrant]

@teodorg would you be able to confirm that the two test cases we've isolated in the three.js issue are reproducible on your Moto G3?

(note: the second issue causes the phone to crash completely and hard-restart, so make sure you don't have anything important open that you'll lose, and I'd recommend testing it in an incognito tab to avoid getting stuck in the same restart loop I did)

https://bugs.chromium.org/p/chromium/issues/detail?id=851870
https://bugs.chromium.org/p/chromium/issues/detail?id=851873

[gabrielgrant]

FWIW it seems this issue is specific to high precision, and so is avoidable in three.js by forcing rendering with mediump. Is there any way to do that in AFrame?

[EerikKivistik]

@gabrielgrant I sent out test builds to some of our users who are having this issue and will report back if "mediump" solves the problem out in the wild. Any ideas on how to detect devices that need to be forced to "mediump" that does not involve doing an offscreen canvas render test on startup?

[EerikKivistik]

@gabrielgrant So far, all the Android 7.0+ devices are rendering on "mediump" with the expected artifacts, but at least materials work. As for older devices running Android 5.0, it seems to make no difference, with everything still rendering completely black.

[gabrielgrant]

@EerikKivistik Oh, interesting -- didn't know this issue affected anything earlier than Android 7.0

In terms of detecting affected devices -- that depends on whether you want to actually test for the failure, or just check for devices that are known to exhibit the issue. AFAIK this fails on devices if, and only if, they have an Adreno 308 GPU.

I think you need to create a canvas to get the webgl context, but i think once you have that canvas, you should be able to do detection on the device params without actually having to render anything. Something like this should do the trick:

let canvas = document.createElement('canvas');
let gl = canvas.getContext('webgl');
let dbgRenderInfo = gl.getExtension("WEBGL_debug_renderer_info");
let unmaskedRenderer = gl.getParameter(dbgRenderInfo.UNMASKED_RENDERER_WEBGL);
let unmaskedVendor = gl.getParameter(dbgRenderInfo.UNMASKED_VENDOR_WEBGL);

My devices report the vendor as Qualcomm and the renderer as Adreno (TM) 308: mrdoob/three.js#14137 (comment)

but I don't know if that is the case for all affected devices. So actually testing the feature is probably safer.

What is the specific rendering test you're using? If you have access to (or have users who have) other affected devices and are able to test, it would be useful to know whether these params (and others; screenshots from webglreport.com would be awesome) are consistent

[gabrielgrant]

@EerikKivistik Looking back at your original list of devices on which you'd seen the failure, they were all Android 7+ (except for the one Android 4.4 device, that i assumed was probably a red herring). Are there other devices you know of now that weren't listed there?

Also curious what artifacts you're seeing? There was some @bhouston had said he thought they "fixed the majority of the issues" with mediump: mrdoob/three.js#14137 (comment)

Edit: actually, looking again, he links to a number of still-unfixed precision issues here: mrdoob/three.js#14137 (comment)

[EerikKivistik]

@gabrielgrant One example I recently discovered is XiaoMi MiPad 2 (Android version 5.1). The medium precision workaround has no effect there.

As for the artifacts I will include a screenshot taken from an Android 7.0 device.

[gabrielgrant]

@EerikKivistik it seems the XiaoMi MiPad 2 has an Intel Atom X5-Z8500 (with an Intel HD Graphics GPU), whereas this issue appears to be specific to the Qualcomm Snapdragon 425, so it sounds like the issue(s) you're seeing with older devices is/are likely some other problem(s) that just happens to have the same symptom. May want to open another issue about those devices (probably against three.js rather than aframe). And in any case, probably best to continue this discussion in mrdoob/three.js#14137

[bhouston]

I think this issue is complex and what we need is a set of reproduction cases that we add as three.js examples - maybe webgl_material_precision_varants.html. It would be the same shader but with highp and mediump in the same scene right beside each other. Maybe modify the weblg_materials_physical_varants.html to do this.

Maybe even use the webgl debug API to get the GPU name and also display the browser string and display it on screen. Then eveyone can screenshot their devices once and you can see the GPU, the OS version, the browser version and also whether it works with mediump and/or highp.

I think this is a complex problem and we need to approach it systematically.

[bhouston]

WE here at Exocortex/Clara.io have more than 25 mobile devices. Once we have a consistent test bed, we can test on each device and share a screenshot. If everyone else does this we can likely pinpoint the issues and we can then work to fix them in a systematic way.

The trick is that each error should be reproducible at once in a single example without modifying any DAT-GUI settings. Thus we only need a single screenshot for each device to know exactly where it stands with regards to bugs.

We do not even have to wait for this to be in the next release, we can use rawgit to view the example in either a PR state or once it is merged into master.

[ngokevin]

Duping with #3971 ... there's a proposed PR ^

[EerikKivistik]

@gabrielgrant We finally went with "mediump" across all Android devices, as distinguishing between all the variations of devices was too complex for the size of our team to handle (and the availability to purchase the specific models was a problem). So far Android 7.0+ seems to be mostly working well. As for Android 5.0, it does produce some artifacts, but we will just have to live with that for the time being.
If anyone has an affected device, please do download 3dc.io on Android and give me feedback on whether or not this issue has also been solved for you. Thank you all for the debugging efforts!

[gabrielgrant]

@EerikKivistik That makes sense. Thanks to you too for all the device reports!

@dmarcos Thanks for finally getting around to tackling this at the aframe level, certainly didn't expect this issue to go quite so deep when I first started delving into it here and in mrdoob/three.js#14137

To confirm, it looks like the change to default precision was reverted in #3988 and then a precision prop was added in #3989

To confirm (and for others finding this issue), the recommendation is to manually set precision to mediump on the a-scene's renderer component, right?

Would it make sense to just set this by default on devices with this GPU? I know doing device-specific fixes shouldn't really be a-frame's responsibility, but this is such a sharp edge that it seems like it might be worth working around.

If this is something you'd be open to, I could probably get a PR together that revives #3977 (making mediump the default) only for these devices