Is anyone else getting positional and rotation oddities with the Microsoft MR Motion Controllers? At my desk the headset’s position is around 1.2 but the controllers… They appear to set their origin (0,0,0) as the headset’s initial position (which isn’t (0,0,0)) and then applies it as world position. Same for rotation. This means visually and functionally the controllers are wildly out of sync. This happens in both the editor and player.
As a workaround, is there a way to set the headset’s initial position to be (0,0,0) instead of applying the floor and position offset from the Portal?
Unity 2017.2.0b10
Windows 10 Insider Preview Build 16281
Windows 10 SDK Preview 16278
The last time I was able to get the controllers to work, the headset would locate at the correct position (where my head was relative to the floor) and the controllers would locate at the incorrect position (under the floor). I am using the same technique that works just fine with Oculus, Vive, and PS Move so I know I am not using an incorrect approach.
This occurs in using the position data provided by UnityEngine.XR.WSA.Input.
Another issue with the controllers is I can’t get them to work from the editor at all. I have to create a build and run from visual studio (which is a challenge posted in another thread).
Two of the three issues I’m reading here are fixed in b11: the incorrect origin for controllers, and the generic InputTracking APIs not working.
We just noticed the rotation is still off if you call the XR.WSA.Input APIs for grip if you start up with your HMD in an orientation other than facing forward (according to when you ran setup), which I see a pretty straightforward fix for, but I’m not sure whether the fix for that will have to wait until point releases.
I wasn’t aware of input being broken for playing in-editor. I’ll have to investigate that as well, but again, the fix for that may have to wait until point releases, not sure.