Open planiitis opened 12 months ago
Well, the code in GyroscopeListener is based on the documentation, so I think it's correct. But I may be wrong, of course!
Unfortunately, I haven't got a shader at hand to test whether this correct or not at the moment. But since this open source, you may of course play around with it and see if you can make it work for your sample 😉
Something tells me either the rotation angles should all be negated, or the vector should rather be multiplied by the inverse of deltaRotationMatrix there in order to make sense.
I think inversing isn't required because:
However, since the matrix is a rotation matrix, its transpose is also its inverse, conveniently, it is often the inverse of the rotation that is needed for rendering; it can therefore be used with OpenGL ES directly.
Well, the code in GyroscopeListener is based on the documentation, so I think it's correct. But I may be wrong, of course!
Looking at the comment in the example code:
// rotationCurrent = rotationCurrent * deltaRotationMatrix;
I believe rotationCurrent
here is meant to be a matrix, not a vector as in the case of GyroscopeListener.rotation
. A rotation matrix can be inverted as needed (and will be by default when provided to OpenGL), a rotated vector cannot be inverted in the same way to get the "inverse-rotated" vector.
I think inversing isn't required because:
However, since the matrix is a rotation matrix, its transpose is also its inverse, conveniently, it is often the inverse of the rotation that is needed for rendering; it can therefore be used with OpenGL ES directly.
Here's how I understand it: If the gyroscope
uniform were a matrix, you'd be right. But it's a vector, so the transposition does not happen.
I made a shader to explore the different orientation vectors: https://gist.github.com/planiitis/d940919503d442f0c7287ae10f74b466
Set Sensor Delay to Game or UI for best results.
The shader provides a view of the gyroscope
, gravity
, magnetic
and linear
vectors, as well as rotationMatrix
. Assuming the device is in its non-rotated screen configuration, you can turn the device around to get a "camera view" of the various vectors.
rotationMatrix
.magnetic
, pointing to magnetic north.gravity
and gravity + linear
, both negated so that they point downwards for convenience and a more intuitive view.gravity
and gyroscope
circles.gyroscope
vector.Current code negates the x
and y
coordinates of the gyroscope
vector. That makes the gyroscope
circle move correctly with respect to the others when rotating the device about its x
or y
coordinate. However, rotation around the device's z
coordinate is still backwards: Try laying the device on a level, non-magnetic surface with its screen facing up, then rotate the device clockwise. If the magnetic
circle is in view, you should see it stay in place relative to yourself, or moving counter-clockwise relative to the device screen, as expected. However, the yellow line that points to the gyroscope
vector will rotate clockwise relative to the device screen, rotating at double speed relative to yourself.
The current
vec3 gyroscope
uniform provides incomplete gyroscope data, as it reduces the 3DOF gyroscope data into a 2DOF constant-length vector.Furthermore, I have trouble interpreting the data. As I understand it, the current gyroscope uniform starts as a vector at [1.0, 1.0, 1.0]. This vector then continuously gets rotated according to gyroscope input. The vector appears to be relative to the device's frame of reference, as by my observations, rotating the device around a single particular sensor axis results in the vector being rotated correspondingly around that particular axis. I haven't been able to make much sense of it beyond that. In particular, I've tried to interpret the
gyroscope
vector as being in the same frame of reference asgravity
,linear
andmagnetic
, but no matter how I try to flip and rotate it, it doesn't fit with the rest of the vectors.I'm no geometer, but could it be that something is backwards in GyroscopeListener.java? Something tells me either the rotation angles should all be negated, or the vector should rather be multiplied by the inverse of
deltaRotationMatrix
there in order to make sense.Possibly, if
GyroscopeListener.rotation
were a rotation matrix rather than a vector, the data might make sense, and if provided as a uniform similar torotationMatrix
, could be used to create vectors that appear to be in the same frame of reference asgravity
andmagnetic
. I understand the following to apply to the existingrotationMatrix
uniform and would expect it to apply fordeltaRotationMatrix
, and by extension, any matrix rotated bydeltaRotationMatrix
as well:Additionally, often one might only care about the angular speed of device rotation. Then a uniform providing either direct access to the gyroscope data or to
deltaRotationMatrix
would make sense.