Open alexshalamov opened 7 years ago
SGTM
Can we actually implement this. I mean on Android the above "AbsoluteOrientationSensor" might use different impl if magnetometer isnt available. Is it possible for us to detect that?
Apart from that, I think this is fine.
@kenchris, it seems your explainer doc does identify high value use cases for all three:
https://w3c.github.io/motion-sensors/#orientation https://w3c.github.io/motion-sensors/#geomagnetic-orientation https://w3c.github.io/motion-sensors/#relative-orientation
That said, the use case for Relative Orientation Sensor ("This avoids the delay which low and high pass filters introduce.") could be more explicit.
Can we actually implement this. I mean on Android the above "AbsoluteOrientationSensor" might use different impl if magnetometer isnt available. Is it possible for us to detect that?
@kenchris Yes, we can always check what low level sensors are supported by the platform.
@kenchris in that perspective (and looks like we all agreed :) ) do you think it's worth renaming Orientation Sensor
into Absolute Orientation Sensor
in https://w3c.github.io/motion-sensors/#orientation ?
If we can do that without instantiating them, awesome, then let's go with this :-)
@pozdnyakov yes that makes sense.
If we can do that without instantiating them, awesome, then let's go with this :-)
we can :D
Reopening the issue, as it should be closed only when last GeomagneticOrientationSensor is specified.
Marked as "Level 2" per WG call decision.
The OrientationSensor interface could define methods and internal slots (quaternion), while subclasses can explicitly define model and what kind of low-level sensors are used for fusion, e.g.: