-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Making differences between floor-offset-relative space and rig-relative space explicit #11035
Conversation
…al space vs floor-offset-relative-space.
com.microsoft.mrtk.input/Simulation/Devices/SimulatedController.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a review of the code files and those look good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks reasonable to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't really look at all the scenes this time around, but the rest seems reasonable!
…ve space explicit (microsoft#11035) * Making reference transform coordinate system explicit * Switching all coordinate transformations to be explicit about rig-local space vs floor-offset-relative-space. * Naming fix * Naming * Revising based on convo with Kurtis * Removing extra properties * Refactoring * Fixing incorrect coordinate space transformation in PolyfillHandRayPoseSource * Playspace math refactor * Lots of simulator fixes * Rearranging rig * Adjusting HIE scene height * SpatialMapping scene update * More descriptive spatial mapping info panel * Adjusting vertical position of all scenes * Making input sim default to Grab anchor due to new (more accurate) ray calculation * Adding Pose property and constructor to HandJointPose * Adding more reasonable overloads/utility methods in PlayspaceUtilities * Fixing device pose math in ArticulatedHandController * PR Feedback * Fixing more scenes to use correct elevation
Overview
So far in MRTK3, we've used device-relative coordinates for everything, with the head always starting at 0,0,0. However,
XROrigin
and Unity XR in general have two different "origin tracking modes":Floor
andDevice
. InFloor
mode, trackables are reported relative to the precalibrated floor elevation; i.e., the coordinate space is absolute. InDevice
mode, trackables are reported relative to the point in space at which the HMD was first detected. Some devices support both (Quest, VR in general), and some devices only supportDevice
mode (HoloLens, etc).This PR makes our rig respect both modes. By default, the XROrigin is now set to
Unspecified
mode, with a default backup floor height of 1.6m. On VR devices with precalibrated floor heights, the device pose(s) will be reported with absolute coordinates, and the Camera Offset object will have an offset of (0,0,0). On devices that only supportDevice
mode, the 1.6m backup offset will be applied to the CameraOffset object.The sample scenes have been re-authored accordingly; all content is now placed at "head height" (1.6m). This is a breaking change, as downstream users will have to re-center their app's content to use appropriate heights/positions. (The alternative would be to set their XROrigins to Device mode only, with the awareness that this may break locomotion or avatars for VR content).
Fixes #11017.
Changes
PlayspaceUtilities.ReferenceTransform
.PlayspaceUtilities.XROrigin.CameraFloorOffsetObject
(for AR trackables like device poses, anchors, and meshes) orPlayspaceUtilities.XROrigin.Origin
for checking where the user's rig (0,0,0) is.XROrigin
andARSessionOrigin
onto the CameraOffset object itselfProxyInteractor
from InputFieldExamplesProxyInteractor
from VirtualizedScrollRectList example sceneInverseTransformPose
helpers toPlayspaceUtilities
InputSimulator
and simulated devices into usingPose
structsInputSimulator
(SimulatedInputPosition/Rotation
->CameraRelativePose
)PolyfillHandRayPoseSource
ArticulatedHandController
(devicePose was assumed to be global)Verification
All existing unit tests pass. Would appreciate verification from the rest of the team testing other VR devices.