Three.js: Losing performance with Oculus Quest and r112

[arturitu]

Description of the problem

I have a VR project that is loading a glTF scene and it was running between 72fps and 62fps (if it is showing more than 40k tris) using r111, but when I changed to r112 it runs at 52fps to 42fps.

I have been testing to edit and back to something similar to r111 code on some of the changes that are listed on https://github.com/mrdoob/three.js/releases but I haven't gotten any improvement.

I think is related to 'WebGLRenderer' but I couldn't test it.

Three.js version

• [X] Dev
• [X] r112

Browser

• [x] Oculus Browser

OS

• [x] Android

Hardware Requirements (graphics card, VR Device, ...)

• [x] Oculus Quest

[Mugen87]

loading a glTF scene

Are you using MeshStandardMaterial then? The implementation has been changed in R112 to solve some conceptual issues with this material. It was reported elsewhere that the performance is a bit worse than before. However, the rendering is now "more correct".

If you have performance issues, try to use a cheaper material like MeshPhongMaterial or even MeshLambertMaterial and see if it helps.

[arturitu]

Yes, I'm using MeshStandardMaterial because is the default that is assigned by Blender when you export a Mesh with Principled BSDF material. I could try to change to PhongMaterial when is parsing but I will lose metalness and roughness. Thanks for the explanation.

[arturitu]

In any case, I tried to revert #18171 on my three.module.js to test if the performance is better but it continues worse than r111. Are there any other changes that affect the MeshStandardMaterial performance?

[Mugen87]

Yes, there were a bunch of PRs that changed the PBR shader code. And I do not recommend to revert single PRs. Better to use R111 in this case.

[arturitu]

I think I got it, #18178 causes this drops in performance. By default gl.getContextAttributes() with Oculus browser are:
antialias: true, alpha: false, depth: true, stencil: true

But the default initLayer on the API is https://www.w3.org/TR/webxr/#xrwebgllayer-interface:

dictionary XRWebGLLayerInit { boolean antialias = true; boolean depth = true; boolean stencil = false; boolean alpha = true; boolean ignoreDepthValues = false; double framebufferScaleFactor = 1.0; };

If you only set alpha to false it works with better performance.

var layerInit = { antialias: attributes.antialias, alpha: false, depth: attributes.antialias, stencil: attributes.stencil };

I don't know if is ok to force it, or it is something that is on the Oculus Browser side. But it should be good if we could have this fixed to have a better performance on VR.

[Mugen87]

I'm not sure I understand. three.js sets the WebGL context parameter alpha to false by default. As long as the application does not set it to true, false is passed to XRWebGLLayer.

[arturitu]

Sorry, my mistake, if you force to set alpha to true it works better:
var layerInit = { antialias: attributes.antialias, alpha: true, depth: attributes.antialias, stencil: attributes.stencil };
Because by default gl.getContextAttributes().alpha is false with Oculus Browser.

[Mugen87]

Um, maybe we should report this issue to Oculus instead. It's strange that the alpha setting has such a noticeable impact on performance 🤔

/ping @Artyom17

[arturitu]

Ok, opened > https://developer.oculus.com/bugs/bug/463364237921559/ thanks

[Artyom17]

Default state of alpha in gl context should be set to 'true' and I just have verified it with a simple test. So, someone sets the alpha to false, it seems to me.

It is known that setting alpha to false for QCOM chipsets (at least for SD821 and SD835) decreases the perf by up to 30%. I've tried to mitigate that by enforcing alpha internally, and I need to verify that this mitigation is still working.

It would be super helpful if you can provide a test case for profiling.

[Mugen87]

So, someone sets the alpha to false, it seems to me.

That would be three.js. As mentioned before, the renderer sets the alpha context parameter to false by default:

https://github.com/mrdoob/three.js/blob/6c8c7e75f0f04888a814fbebd395cb2055151711/src/renderers/WebGLRenderer.js#L58

[arturitu]

I made a test case here:
https://pacific-globeflower.glitch.me/ It is working around 50fps on Oculus Quest.

And here is fixed, with only changed on three.js file is the line 22998 (Forcing alpha: true instead alpha: attributes.alpha) and it is working around 72fps:
https://pacific-globeflower.glitch.me/fixed.html

[toji]

Confirmed that I'm observing this makes a big difference on Oculus hardware as well. (Thanks for digging up the cause, @arturitu!)

In my case I'm seeing a scene that's running pretty consistently on a Quest at 56-60 FPS with alpha: false rock a super steady 72 FPS with alpha: true on the XRWebGLLayer.

[mrdoob]

@Artyom17

Any chance the Oculus Browser could emulate alpha: false using alpha: true on relevant headsets/GPUs? I think it would be great if we could hide this from users.

[Artyom17]

@mrdoob this is what i am (was) trying to do as aforementioned mitigation strategy, but it seems that something went wrong with it. I am investigating.

[Artyom17]

Ok, found the issue, and yeah the issue was indeed in the broken workaround for the slow RGB render targets. I've fixed it and now it seem to work as fast as RGBA.
The fix will be released in OB 7.2 (ETA - Feb 2020).