I'm building a Unity plugin that supports different game controller types, including phone motion controls. I want to use device orientation to obtain three angles describing the phone's rotation. However, when the phone is held in portrait mode and rotated around what seems like a single physical axis, both gamma and alpha change. The behavior is confusing, and I'm not sure how screen orientation and the device coordinate system affect the values. Is there a reliable way to calculate the phone's orientation for use in Unity, and can I convert the result back into three angles if necessary?
3 Answers
The alpha, beta, and gamma values are Euler angles, and they’re reported relative to the device and screen coordinate systems rather than as three completely independent world-axis rotations. Because the rotations are applied in a specific order, rotating around one physical axis can change more than one reported angle. Screen rotation can also change the reference frame. You should account for screen.orientation.angle or the equivalent orientation value before mapping the result to Unity axes.
For the actual orientation math, converting alpha, beta, and gamma into a quaternion is usually much more reliable than manipulating the Euler angles directly. Quaternions avoid the gimbal-lock and axis-coupling problems that make the raw values look strange. The conversion uses the device orientation order defined by the API, then you’ll need to swap or negate axes because browser device coordinates and Unity’s coordinate system don’t match exactly. If available, an absolute orientation sensor that supplies a quaternion directly can simplify this further.
I’d still like to end up with three angles after converting to a quaternion. Is that possible, or does converting back cause information to be lost?
You can convert a quaternion back to Euler angles, but the result depends on the rotation order you choose and may not be unique. Different sets of Euler angles can represent the same orientation, and gimbal lock can make some orientations unstable or cause the values to jump. It’s best to keep the quaternion internally for calculations and only convert to angles when displaying values or driving something that specifically requires Euler angles. For relative motion, device-motion rotation rates can also be useful, but they measure changes over time and will drift if integrated without correction.
So if I compensate for the screen orientation first, can I use the returned values to get the phone’s rotation correctly in every position?