Mobile has trouble with "forward" in landscape mode about webvr-polyfill HOT 7 CLOSED

My temporary workaround for this was to apply the screen rotation Q in resetPose.

  this.resetQ.copy(this.filter.getOrientation());
  this.resetQ.multiply(this.worldToScreenQ);

Unfortunately, that wouldn't work on Android because of the screen locking stuff. It seems that window.orientation just gives the locked orientation (with no indication that it is indeed locked), so the rotation was wrong if you entered VR mode form anything other than landscape-primary.

My workaround there was to just disable screen locking, though then I had to mess with the instructions display to make it work with the fullscreen wrapper.

from webvr-polyfill.

Just to clarify this issue, it happens only when starting in landscape mode—"forward" appears 90 degrees to the left or right depending on device orientation.

from webvr-polyfill.

I've tinkered with this a bit more and still haven't come to a satisfactory solution.

To summarize, the initial world transformation should account for the device orientation, as should calls to resetPose. Unfortunately, when the orientation is locked on Android, it always returns the locked value, not the true orientation, which makes it difficult to account for.

I'm not sure how to fix this without knowing the "true" orientation.

from webvr-polyfill.

We are using a "preparation" step to access the VR mode:

• unlock the orientation (if it was locked)
• display some instructions, asking the user to turn his phone
• detect orientation changes and only display the button to enter VR when the phone is in landscape
• when the user click on the button, reset the device sensor + do all the VR stuff (fullscreen, orientation lock, distortion, etc...)

We have a trick to detect the orientation even if it's locked at the OS level, we use the event.accelerationIncludingGravity.y value on devicemotion, the phone should be in landscape when the value is around 0 (it works only if the phone is perpendicular to the earth actually)...

We are still using an old version of the WebVR polyfill, without the requestPresent method, but anyhow, those steps have to be done before entering VR, so before requestPresent.

from webvr-polyfill.

I addressed this slightly, but it's still not perfect. c6720ed

from webvr-polyfill.

Alright, should be fixed now: 716f8a1

from webvr-polyfill.

Great news! Thanks!

from webvr-polyfill.