Controllers are positioned inside the headset

VERIFIED FIXED in Firefox 56

Status

()

defect
VERIFIED FIXED
2 years ago
2 years ago

People

(Reporter: ccomorasu, Assigned: daoshengmu)

Tracking

Trunk
mozilla56
All
Windows 10
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox54 disabled, firefox55 wontfix, firefox56 verified, firefox57 verified, firefox58 verified)

Details

Attachments

(2 attachments)

[Affected versions]:
 Fx 55.0.10

[Affected platforms]:
 Windows 10 x64

[Steps to reproduce]:
 1. Launch Fx and go to https://aframe.io/a-painter/ .
 2. Leave the controllers one next to the other.
 3. Click from the page the VR button to start the demo..
 
[Expected result]:
 The controllers are positioned accordingly in the VR.

[Actual result]:
 The controllers are positioned inside the headset.

[Regression range]:
 This is not a regression as this feature is new.
We sometimes get the wrong eye height that makes the controllers are positioned inside the headset.
We should determine if this is a bug in the browser or in the site.

Please advise if this is reproducible on the simpler test site:

https://webvr.info/samples/XX-vr-controllers.html

Thanks!
Flags: needinfo?(cristian.comorasu)
:dmarcos and :cvan have seen this issue on the simpler test sites and non-A-Frame content, too.

One suspicion is that this happens when the Steam VR services are starting up initially. :caseyyee said that this issue also persists across refresh of a page but not after tab close and load.

:daoshengmu has seen this in Rift in A-Painter.
I've seen this problem in numerous occasions but never found a reliable series of steps to reproduce and then investigate. Cristian, do you have a consistent way to reproduce?
I can see the my Oculus Rift inside of my Touch when it doesn't move at the beginning in FF 57 and 55.0b12. After I start to move my Touch, I can see my Touches at the right place in the VR scene. Therefore, I looks like just a problem for the user experience, not a blocker from the platform side.
(In reply to Daosheng Mu[:daoshengmu] from comment #5)
> I can see the my Oculus Rift inside of my Touch when it doesn't move at the
> beginning in FF 56.0a1 (2017-07-25) and 55.0b12. After I start to move my Touch, I can see my
> Touches at the right place in the VR scene. Therefore, I looks like just a
> problem for the user experience, not a blocker from the platform side.
[Affected versions]:
 FF 56.0a1 (2017-07-25) and 55.0b12

[Steps to reproduce]:
1. Use Oculus Rift/Touch and go to https://aframe.io/a-painter/.
2. Click the VR button to start the demo. You can see it work properly. The HMD and controllers are at the right position.
3. Click the exit VR button. The HMD and controllers are still at the right position at the browser.
4. Click the enter VR button again, You will see the HMD is on the floor, and the Touches are at the space. If we refresh the page and enter VR again, it will work properly and has the right position for both Touch and Rift.

[Expected result]:
 The controllers are positioned accordingly in the VR.

[Actual result]:
 After existing from the present mode and enter again, the Oculus Touch and Rift are positioned wrong.
I collected the same position result from Rift and Touch between this two times of entering VR mode.
1)
Rift (-0.041, 0.264, 0.0066)
Touch 1 (-0.07754, -0.1811, -0.228)
Touch 2 (0.091, -0.186, -0.2214)

2)
Rift (-0.039, 0.25, 0.009)
Touch 1 (0.044, -0.1811, -0.211)
Touch 2 (0.038, -0.193, -0.210)

I suppose this is a transform bug of mSittingToStandingTransform for Oculus Rift. I saw I am at the standing position for my first enter VR, but I am at the sitting position for the next time enter VR.
However, Oculus Touch is at the standing position between this two times.
Good catch. I've also seen user height problems with HTC Vive where I enter VR and the headset is on the ground. Page reloads don't seem to fix the problem but a browser restart usually fixes it.
Reloading pages works for me. I have to exit from the present mode and then reloading it. But, after we enter->exit->enter to the present mode, we will get the wrong position.
I notice the the HMD position is different between OpenVR and Oculus. We can compare https://aframe.io/a-painter/, https://aframe.io/examples/showcase/helloworld/, https://aframe.io/examples/showcase/tracked-controllers/, and https://webvr.info/samples/XX-vr-controllers.html.

In the case of Oculus,
A-Painter, we have to reload page to fix the position problem.
helloworld, always good.
tracked-controllers, always good.
XX-vr-controllers, always good.

In the case of OpenVR
A-Painter, we have to reload page to fix the position problem.
helloworld, HMD is always on the floor, reloading doesn't work.
tracked-controllers, HMD is always on the floor, reloading doesn't work.
XX-vr-controllers, always good.
If I open https://webvr.info/samples/XX-vr-controllers.html with the controllers on the table they appears somewhere in the space. I can click the buttons, and rotate and move the a little bit, but I need to move then a bit more so they will jump to the correct position and they'll just stay there. 

A video showing the described effect: https://www.youtube.com/watch?v=z5ItBrsJpI0

I've reproduced it also in apainter where the controllers appears on the head, but as soon as I move them a bit they jump to the desired position.
(In reply to Daosheng Mu[:daoshengmu] from comment #11)
> I notice the the HMD position is different between OpenVR and Oculus. We can
> compare https://aframe.io/a-painter/,
> https://aframe.io/examples/showcase/helloworld/,
> https://aframe.io/examples/showcase/tracked-controllers/, and
> https://webvr.info/samples/XX-vr-controllers.html.
> 
> In the case of Oculus,
> A-Painter, we have to reload page to fix the position problem.
> helloworld, always good.
> tracked-controllers, always good.
> XX-vr-controllers, always good.

I can reproduce the issue with A-painter 100% of the times, when I enter VR, exit and then re-enter VR again the headset is in the floor. But it works as expected for the rest of A-Frame demos. The A-Frame demos are using 0.6.1 while A-Painter is using 0.5.0, so I guess it was a bug that it's already solved in A-Frame, so definitely it's a content issue not a browser bug, as I can't also reproduce it on the webvr.info examples.
I'll try to migrate a-painter to 0.6.0 to check if the issues goes away.
Controllers are positioned inside the headset is because Touch will idle when we didn't move it for a while. It will not have the tracked flag of its position or orientation, so I didn't fetch its pose state before.

One way I can do is force to update the tracking state when Touch is added. The position should be the last time update information. It would not be correct sometimes but it would not be at the origin at least.

Kip, are you ok with this?
From the HTC Vive side, their controllers will always have tracking data of pose when it wakes up from sleep.
(In reply to Daosheng Mu[:daoshengmu] from comment #16)
> Created attachment 8890740 [details]
> Bug 1383110 - Force to fetch Oculus Touch tracking data when it is added;
> 
> Review commit: https://reviewboard.mozilla.org/r/161942/diff/#index_header
> See other reviews: https://reviewboard.mozilla.org/r/161942/

Kip, please take a loot at the Comment 14 and help me review it. Thank.
Assignee: nobody → dmu
(In reply to Daosheng Mu[:daoshengmu] from comment #11)
> I notice the the HMD position is different between OpenVR and Oculus. We can
> compare https://aframe.io/a-painter/,
> https://aframe.io/examples/showcase/helloworld/,
> https://aframe.io/examples/showcase/tracked-controllers/, and
> https://webvr.info/samples/XX-vr-controllers.html.
> 
> In the case of Oculus,
> A-Painter, we have to reload page to fix the position problem.
> helloworld, always good.
> tracked-controllers, always good.
> XX-vr-controllers, always good.
> 
> In the case of OpenVR
> A-Painter, we have to reload page to fix the position problem.
> helloworld, HMD is always on the floor, reloading doesn't work.
> tracked-controllers, HMD is always on the floor, reloading doesn't work.
> XX-vr-controllers, always good.

I can't reproduce the bug on Vive with helloworld and tracked-controls. The HMD seems to be always in the correct position and never on the floor.
A-Painter starts in the correct position but if I exit and then enter VR again it goes to the floor because of a bug with the current deployed version of aframe, but with the updated version (https://fernandojsg.github.io/a-painter/) it works as expected too.
(In reply to Daosheng Mu[:daoshengmu] from comment #14)
> Controllers are positioned inside the headset is because Touch will idle
> when we didn't move it for a while. It will not have the tracked flag of its
> position or orientation, so I didn't fetch its pose state before.
> 
> One way I can do is force to update the tracking state when Touch is added.
> The position should be the last time update information. It would not be
> correct sometimes but it would not be at the origin at least.
> 
> Kip, are you ok with this?

This sounds reasonable -- I suggest that we proceed with this approach and get feedback from users.  It sounds logical that if the controller went to sleep due to lack of movement, that it's probably still in the same place and will wake up if someone grabs it.
Comment on attachment 8890740 [details]
Bug 1383110 - Force to fetch Oculus Touch tracking data when it is added;

https://reviewboard.mozilla.org/r/161942/#review167518

Looks good, thanks!
Attachment #8890740 - Flags: review?(kgilbert) → review+
Pushed by dmu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/047029e0a1d4
Force to fetch Oculus Touch tracking data when it is added; r=kip
https://hg.mozilla.org/mozilla-central/rev/047029e0a1d4
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
I re-tested using Fx 55.0b13.
This issue is reproducible 100% on a-frame paint via Oculus on the first try, second attempts have 40% chances of at least one remote to be in the headset.
Flags: needinfo?(cristian.comorasu)
(In reply to Cristian Comorasu [:CristiComo] from comment #23)
> I re-tested using Fx 55.0b13.
> This issue is reproducible 100% on a-frame paint via Oculus on the first
> try, second attempts have 40% chances of at least one remote to be in the
> headset.

We should test it in FF Nightly. The version should be after 56.0a1 (2017-07-28). I am considering if uplifting it to v.55. Because it is not a crash bug, and we are a little bit too late to catch the release train.
(In reply to Daosheng Mu[:daoshengmu] from comment #11)
> I notice the the HMD position is different between OpenVR and Oculus. We can
> compare https://aframe.io/a-painter/,
> https://aframe.io/examples/showcase/helloworld/,
> https://aframe.io/examples/showcase/tracked-controllers/, and
> https://webvr.info/samples/XX-vr-controllers.html.
> 
> In the case of Oculus,
> A-Painter, we have to reload page to fix the position problem.
> helloworld, always good.
> tracked-controllers, always good.
> XX-vr-controllers, always good.
> 
> In the case of OpenVR
> A-Painter, we have to reload page to fix the position problem.
> helloworld, HMD is always on the floor, reloading doesn't work.
> tracked-controllers, HMD is always on the floor, reloading doesn't work.
> XX-vr-controllers, always good.

I move the OpenVR display position on the floor bug at Bug 1384865.
See Also: → 1384865
I re-verified using Fx56.0-build6, Fx 57.0b5 and Fx 58.0a1 (build ID: 20171004100049) on Windows 10 x64 and I can confirm this issue is fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.