Expose controller's IMU pose for improved throwing physics?

[klausw]

Oliver Kreylos recently posted a detailed video about throwing physics in VR: https://www.youtube.com/watch?v=eREYrwCwqYo

The key points are that it's important to use the controller's linear and angular velocities (now available, cf. issue #619 and the corresponding fields in XRPose), and that the calculation should use a cross product of the angular velocity with the vector from the controller's IMU position to the object's center of gravity.

If I'm understanding it right, gripSpace is the pose that should be used to render virtual objects such that they appear to be held in the user’s hand which isn't necessarily equivalent to the IMU position.

Would it be appropriate to expose an imuSpace, or equivalently a static offset between gripSpace and imuSpace? This could potentially also be done as part of the input profiles library since it's a fixed property of the controller.

[klausw]

As @toji pointed out in a Twitter discussion, an implementation can (and should) incorporate the known offset when it's reporting linear and angular velocities. I think it may be worth adding a note to the spec to point this out, at least it wasn't obvious to me.

For example, imagine a controller being rotated around the IMU center, so that the linear velocity reported by the IMU is zero. The offset gripSpace origin would be moving along an arc with a nonzero linear velocity, and the system needs to incorporate a correction factor (I think the angularVelocity ⨯ offset cross product) to adjust for this when reporting linear velocity in gripSpace. If the system simply reported the IMU values as-is, the velocities would not match.