Alternative orientation representations?

[marcoscaceres]

The spec contains quite a lot of math to convert the APIs return value into other representations. As show in the examples, that makes for a lot of complex mathematical conversations in JS.

Why don't we allow instead allow developers to request some common alternatives representations? Or provide some static methods to do the conversion (.toQuaternions() or whatever). That would make the API potentially more developer friendly without needing developers to do a bunch of complicated mathematical conversions themselves.

[marcoscaceres]

See also the compass heading example... one would hope that getting a compass heading wouldn't require an entire A4 piece of paper worth of linear algebra, trigonometry, and/or calculus.

[anssiko]

Is the proposal here to retrofit all these features into one specification? And refer to the Orientation Sensor and Magnetometer specifications for these features?

Orientation Sensor provides quaternion and rotation matrix representations:
https://www.w3.org/TR/orientation-sensor/#orientationsensor-quaternion
https://www.w3.org/TR/orientation-sensor/#orientationsensor-populatematrix

Also conversions:
https://www.w3.org/TR/orientation-sensor/#convert-quaternion-to-rotation-matrix
https://www.w3.org/TR/orientation-sensor/#helper-create-quaternion-from-euler-angles

With Magnetometer the compass heading use cases is three lines of code (or with the declination angle, a few more):
https://www.w3.org/TR/magnetometer/#compass

I can share our group's experience that might be helpful. If you try to retrofit these features you'll end up eventually pulling in the rest of the feature dependencies after realizing what it takes to do this properly (speaking from a collective experience, been there...). To take one example: in animation frame loop-based situations, if you can't ask for a sensor update frequency (within safe bounds), you can't match it with the animation frame rate. This means bad user experience, see motion-to-photon delay. What I'm saying is there's a reason why the Generic Sensor-based APIs have a modern shape they have. It was an outcome of a deliberate design process baking in learnings from industry experts in this field over many years. There's a write up by our original author explaining the broader picture (https://www.bocoup.com/work/generic-sensor-api-for-the-web-platform) and a ton of deep technical discussions can be founds from the GH repos spanning back 10+ years.

Circling back to the features proposed: we added these features to the Orientation Sensor, because we heard from web developers this type of abstractions work better with e.g. WebGL or WebGPU, matrix and vector libraries needed to create low-latency motion-driven 3D experiences for the web. Similarly, we heard from web developers that getting compass heading is complicated so we designed the Magnetometer to make that use case simple.

You seem to be paving the same path now we did 10 years ago. The realities of physics haven't changed, so I wouldn't expect different results, except that you are retrofitting to an API that is not designed to be extensible.

[marcoscaceres]

The realities of physics haven't changed, so I wouldn't expect different results, except that you are retrofitting to an API that is not designed to be extensible.

How is it not extensible? I don't see any issue with bringing the things you listed above to the Device Orientation and Motion spec?

Given the lack of interest from other implementers in the additional specifications, it may be more effective to integrate that functionality into the existing ones. The current approach seems to conflict with the TAG's new features design principles.

According to these principles: "Before adding items, consider integration with existing, similar capabilities." It appears that there was limited effort to integrate similar capabilities, leading to specifications that are implemented by only one engine and are not adopted by other browser vendors.

Wouldn't it be better to add the functionality to this spec (which we should do regardless)?

[reillyeon]

I expect that developers using these sensors as the input to other calculations have access to libraries which can perform these types of conversions. I think the more important question is whether any precision is lost in converting the orientation data provided by the platform to Euler angles. For example, on Android the system natively provides a quaternion and so conversion is required to construct a DeviceOrientationEvent while it is not required to update the reading provided by an OrientationSensor. Adding a quaternion accessor here (and performing conversion to Euler angles lazily) might be more efficient on that platform.