Camera Y position incorrect in some cases while in VR

[machenmusik]

mchen [12:59 PM]
interesting default camera Y height behavior with current master...
http://codepen.io/machenmusik/pen/JWXGap

With Rift and latest Chromium, when using the auto-enter/exit VR, user height is correct both outside VR (default user height 1.6) and in VR (true HMD height), first time and every time. That consistency is provided by #2428.

With Rift and latest Chromium, when manually clicking the enter VR button but not wearing the HMD, user height is correct outside VR (default user height 1.6) but wrong inside VR (e,g, camera placed higher than true HMD height once you put it on).

With Rift and latest Nightly, it appears that vrdisplayactivate is not working and therefore neither is auto-enter VR (i.e. you put on the Rift, see nothing, and still have to click the button).

With Rift and latest Nightly, when manually clicking the enter VR button but not wearing the HMD, user height is always 1.6 since it just goes fullscreen and doesn't try to enter VR at all. In fact, it won't try to enter VR at all unless you reload the page.

With Rift and latest Nightly, when manually clicking the enter VR button while wearing the HMD, user height is correct outside VR (default user height 1.6) but wrong inside VR (e,g, camera placed lower than true HMD height once you put it on, apparently by 1.6 the default user height), first time and every time. That consistency is provided by #2428.

So two apparent bugs:
(1) Nightly vrdisplayactivate is not working.
(2) Manually entering VR via UI button seems to have some issue with getting initial HMD position/height, and since applied as deltas by look-controls, that stays wrong while in VR.

[machenmusik]

using http://chenz.org/vr-camera-height.html to avoid any potential issues with codepen,
same behavior above is seen.

[machenmusik]

With Rift,

if you place a breakpoint at src/components/look-controls.js line 214
and then evaluate some variables in console,

Nightly, which does NOT work properly, does NOT return stageParameters:

this.dolly.position
Object { x: 0.2644968032836914, y: -0.8083080649375916, z: -0.9467211961746216 }
this.controls.getVRDisplay()
VRDisplay { isConnected: true, isPresenting: true, capabilities: VRDisplayCapabilities, stageParameters: null, displayId: 1, displayName: "Oculus VR HMD", depthNear: 0.005, depthFar: 10000 }

Chromium, which works properly, does provide stageParameters:

this.dolly.position
Vector3 {x: 0.009547733701765537, y: 0.5052434802055359, z: 0.014989607967436314}
this.controls.getVRDisplay().stageParameters
VRStageParameters {sittingToStandingTransform: Float32Array[16], sizeX: 2.0250000953674316, sizeZ: 2.0250000953674316}

[machenmusik]

With Vive,

if you place a breakpoint at src/components/look-controls.js line 214
and then evaluate some variables in console,

Nightly works properly, and stageParameters are returned:

this.dolly.position
Object { x: 0, y: 0.75, z: 0 }
this.controls.getVRDisplay().stageParameters
VRStageParameters { sittingToStandingTransform: [16], sizeX: 1, sizeZ: 1 }

Chromium, which also works properly, does provide stageParameters:

this.dolly.position
Vector3 {x: -1.1390511989593506, y: 0.31331753730773926, z: -0.6187263131141663}
this.controls.getVRDisplay().stageParameters
VRStageParameters {sittingToStandingTransform: Float32Array[16], sizeX: 0, sizeZ: 0}

[machenmusik]

So it appears that the camera height issue is result of a bug in Oculus Rift support in Nightly where the stageParameters are not returned on the VRDisplay, and so the code cannot correctly adjust for roomscale.

Who from Mozilla can confirm and address? @kearwood? @cvan?

[kearwood]

Thanks for spotting the missing stageParameters for Oculus. Oculus wasn't capable of roomscale when we first implemented support. Since then, we have updated to the newer Oculus SDK with support for the Oculus Guardian system and will be adding stageParameters for Oculus:

https://bugzilla.mozilla.org/show_bug.cgi?id=1344393

You can expect this to be implemented early next week.

[machenmusik]

Great, thanks @kearwood! While modernizing, it would be great to expose capacitive events for Oculus Touch, but that is probably a little more work.

[machenmusik]

sorry I haven't had time yet - anyone had a chance to test latest Nightly with Rift for stageParameters?

[machenmusik]

latest Nightly exhibits same behavior @kearwood

[machenmusik]

Running latest Nightly, I now see that Rift HMD height is correct, but the Touch controllers are still in the floor the way the HMD used to be :-/ @kearwood thoughts?

[machenmusik]

Codepen for the Y height issue which appears to now impact Touch controller, not HMD...
http://codepen.io/machenmusik/pen/aJNejw
@dmarcos @ngokevin @kearwood let me know if you would prefer to close this issue and open a new one on the controller.

[cvan]

@caseyyee ping here for your experiences

[machenmusik]

(@fernandojsg do you see this with your recent A-Blast Touch changes?)

[caseyyee]

I would think it's something like the room transform not being applied to the controller pose? ie:

https://github.com/mrdoob/three.js/blob/dev/examples/js/controls/VRControls.js#L127

[machenmusik]

(not sure why that should differ across browsers though?)

[machenmusik]

looks like tracked-controls should be doing this already? (before my time though)
https://github.com/aframevr/aframe/blob/master/src/components/tracked-controls.js#L87
https://github.com/aframevr/aframe/blob/master/src/systems/tracked-controls.js#L17

[machenmusik]

patch for applying user height when null stageParameters in #2446 but should probably test with daydream controller to make sute it doesn't break 3DoF

[caseyyee]

@machenmusik can we break that commit into a separate PR? I think the emulation pieces need to be discussed in more detail before we can commit to those changes.

I will give it a spin on daydream and report

Hugely appreciate the patches!

[machenmusik]

i think that commit may be separable, but you can try it on daydream now using chenzlabs master via rawgit (which I think I have codepen for...)

[caseyyee]

Horray! I just cherry picked the commit 53d72ca and it seems to resolve the issue with the rift and also works with daydream as well.

[machenmusik]

ok great! i am tied up for some time, if you want to do a PR with just that cherry pick feel free - but I do think we should commit the rest of the changes needed to fully leverage recent Nightly support for Oculus Touch ASAP, or else the controllers still won't be entirely usable

[caseyyee]

@machenmusik gotcha. Will take a look at the rest of the PR.

[machenmusik]

I got a few minutes to submit #2510