Three.js: VREffect on mobile devices force setPixelRatio to 1
When you enter on fullscreen mode force setPixelRatio to 1 and the render looks with very low resolution on mobile devices.
https://github.com/mrdoob/three.js/blob/dev/examples/js/effects/VREffect.js#L126
Is it force it for performance reasons or is an issue?
arturitu
All 7 comments
/ping @brianchirls
mrdoob
on 23 Sep 2016
I believe this is correct as it is. The eyeWidth and eyeHeight already account for the full resolution of the HMD's display, so there's no need for any additional multiplication by devicePixelRatio.
There are a couple reasons why the image might not look great on mobile, in particular if you're using webvr-polyfill:
1) The polyfill has to render to a texture, which is then passed through a post-processing effect for the distortion. In WebGL 1.0, rendering to a shader disables antialiasing, so the image looks a bit degraded. I think you could work around this (and get better performance) by doing all the distortion in a single pass in vertex shaders, which is what Cardboard Design Lab does. But that's pretty hard.
2) webvr-polyfill has a configuration option called BUFFER_SCALE, which is set to 0.5 by default, and forces the image to not render at full scale. You could set this higher, but you might sacrifice frame rate, which could be bad. So you need to find the right balance and test on different devices. It's worth noting that in the Oculus best practices for mobile, they recommend only rendering at 1024x1024 per eye. And that's for the S6, which is not the fastest phone around, but also far from the slowest.
If you're referring to Samsung Internet for GearVR, which does not require the polyfill, well, the webvr implementation in that browser still needs work. So don't expect it to look great in there just yet.
brianchirls
on 25 Sep 2016
@arturitu Maybe there's something going on with the polyfill? See https://github.com/borismus/webvr-polyfill/issues/156
brianchirls
on 28 Sep 2016
Sorry @brianchirls I didn't have time to answer your previous detailed comment, because I wanted to make some examples with and without polyfill and the last and older VREffect/Controls.
I have the impression that with previous versions of VREffect works better with the real pixel ratio of the device (for example testing with a Nexus5 is 3 and now only render at 20-30fps for a very simple scene). And another thing that surprise me is that in Sketchfab the models seems to work better performance with more pixelRatio. If I have time until the end of the week I will try to make some examples to compare the performance.
arturitu
on 28 Sep 2016
Yeah I'd love to see your examples. If there's a real problem here let's
get it fixed.
On Sep 28, 2016 12:34 PM, "Arturo Paracuellos" [email protected]
wrote:
Sorry @brianchirls https://github.com/brianchirls I didn't have time to
answer your previous detailed comment, because I wanted to make some
examples with and without polyfill and the last and older VREffect/Controls.I have the impression that with previous versions of VREffect works better
with the real pixel ratio of the device (for example testing with a Nexus5
is 3 and now only render at 20-30fps for a very simple scene). And another
thing that surprise me is that in Sketchfab the models seems to work better
performance with more pixelRatio. If I have time until the end of the week
I will try to make some examples to compare the performance.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mrdoob/three.js/issues/9749#issuecomment-250221945,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAeDA8PDrBXA3K9eXrUh85RVczNNNNN8ks5qupcLgaJpZM4KEnKL
.
brianchirls
on 28 Sep 2016
Ok, @brianchirls are agree, if you set BUFFER_SCALE to 1.0 it render with the correct devicePixelRatio. And I had a problem with the performance because I forgot to change antialias to false, sorry.
arturitu
on 3 Oct 2016
I'm having the same issue and setting BUFFER_SCALE to 1.0 didn't help. The reason is that WebVR on my phone (Huawei P20) uses the native VR display instead of the polyfill version (I found that out via debugger). BUFFER_SCALE only has effect if the CardboardVRDisplay VR display is used, which is not the case if native VR display is available.
I have managed to fix the problem by manually setting the correct pixel ratio calling (devicePixelRatio) by calling renderer.setPixelRatio after each call to vrEffect.setSize (in the onResize function).
knee-cola
on 26 Jan 2019
Related issues
scrubs
·
3Comments
boyravikumar
·
3Comments
donmccurdy
·
3Comments
danieljack
·
3Comments
konijn
·
3Comments
Most helpful comment
I believe this is correct as it is. The
eyeWidthandeyeHeightalready account for the full resolution of the HMD's display, so there's no need for any additional multiplication bydevicePixelRatio.There are a couple reasons why the image might not look great on mobile, in particular if you're using webvr-polyfill:
1) The polyfill has to render to a texture, which is then passed through a post-processing effect for the distortion. In WebGL 1.0, rendering to a shader disables antialiasing, so the image looks a bit degraded. I think you could work around this (and get better performance) by doing all the distortion in a single pass in vertex shaders, which is what Cardboard Design Lab does. But that's pretty hard.
2) webvr-polyfill has a configuration option called
BUFFER_SCALE, which is set to 0.5 by default, and forces the image to not render at full scale. You could set this higher, but you might sacrifice frame rate, which could be bad. So you need to find the right balance and test on different devices. It's worth noting that in the Oculus best practices for mobile, they recommend only rendering at 1024x1024 per eye. And that's for the S6, which is not the fastest phone around, but also far from the slowest.If you're referring to Samsung Internet for GearVR, which does not require the polyfill, well, the webvr implementation in that browser still needs work. So don't expect it to look great in there just yet.