search

immersive-web / cardboard-vr-display

A JavaScript implementation of a WebVR 1.1 VRDisplay
https://immersive-web.github.io/cardboard-vr-display
Apache License 2.0
91 stars 43 forks source link

Fallback to device motion events if the Sensor emits an error event #23

Closed jsantell closed 6 years ago

jsantell commented 6 years ago

Currently, when using the Sensor API, if it's not possible to create, we fall back to device motion. What isn't handled is when the sensor emits an error event -- it does not currently fall back to device motion.

Unfortunately, I'm not sure how to test this without devices that do not support these features, such that would create an async failure, as opposed to the synchronous thrown errors. Any ideas? @cvan @kenchris @pozdnyakov

reillyeon commented 6 years ago

Before falling back to 'deviceorientation' events can we try to switch to AbsoluteOrientationSensor?

jsantell commented 6 years ago

I'll be honest, I'm not too clear on the differences between AbsoluteOrientationSensor and RelativeOrientationSensor and how to cast between the two coordinate systems

reillyeon commented 6 years ago

The two sensors produce the same type of data. The difference is that the AbsoluteOrientationSensor uses input from the magnetometer to provide an orientation relative to magnetic North rather than an arbitrarily chosen initial heading.

Reference: https://w3c.github.io/orientation-sensor/#absoluteorientationsensor-model

jsantell commented 6 years ago

I'm not sure how to translate AbsoluteOrientationSensor data's origin to that of RelativeOrientationSensor's origin, so that the user is facing down -Z initially. Not terribly familiar with the sensor fusion code that translates between coordinates. Anyways, if RelativeOrientationSensor (acc,gyro) doesn't work, why would AbsoluteOrientationSensor (acc,gyro, magnet) work, which actually has more underlying hardware dependencies?

More pressing though, what causes this error case? Only on devices that have the API implemented, but no underlying gyroscope/accelerometer?

reillyeon commented 6 years ago

It's entirely opaque to Chrome why the Android platform doesn't support one sensor type or another. If we ask for TYPE_GAME_ROTATION_VECTOR (which is what the RelativeOrientationSensor is based on) and the platform doesn't support Chrome can try to build a fusion sensor on its own based on the low-level components.

I don't know why these particular devices don't support TYPE_GAME_ROTATION_VECTOR, the fact that after falling back to the old sensor events everything works indicates that they do either support TYPE_ROTATION_VECTOR or both TYPE_ACCELEROMETER and TYPE_MAGNETIC_FIELD. Maybe they don't have a gyroscope.

jsantell commented 6 years ago

Trying out the AbsoluteOrientationSensor and it's producing different results. Looks roughly like it's -PI/2 off on the Y compared to RelativeOrientationSensor after going through the transformations to VR space (due to not currently using referenceFrame https://github.com/immersive-web/cardboard-vr-display/issues/17). Can file an issue for this in a follow up, but what I'm seeing does not match up with my understanding of AbsoluteOrientationSensor