Closed Bug 1384865 Opened 7 years ago Closed 7 years ago

OpenVR VRDisplay position is on the floor

Categories

(Core :: WebVR, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla56
Tracking Status
firefox56 --- fixed

People

(Reporter: daoshengmu, Assigned: daoshengmu)

References

Details

Attachments

(1 file)

According to https://bugzilla.mozilla.org/show_bug.cgi?id=1383110#c11, we notice we have different behavior between Oculus Rift and HTC Vive. I suppose Rift is correct. Because OpenVR display in some demos has unreasonable results.
Assignee: nobody → dmu
It looks like the game pose is the world space that we want. The Render pose is an object space of VRDisplay.
Using GetDeviceToAbsoluteTrackingPose has the same result as using WaitGetPoses() to get game poses. I prefer WaitGetPoses(), because WaitGetPoses() we always need it.
I've been trying to reproduce the bug as discussing https://bugzilla.mozilla.org/show_bug.cgi?id=1383110#c11 with the latest release but I'm not able to see the display on the floor, on every demo it's working as expected for me.
Comment on attachment 8890765 [details]
Bug 1384865 - Using game pose of OpenVR VRDisplay instead of render pose;

https://reviewboard.mozilla.org/r/161966/#review167514

LGTM, Thanks!
Attachment #8890765 - Flags: review?(kgilbert) → review+
Pushed by dmu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/113b17f0f95d
Using game pose of OpenVR VRDisplay instead of render pose; r=kip
https://hg.mozilla.org/mozilla-central/rev/113b17f0f95d
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
See Also: → 1383110
I'm still seeing this issue in 56.0a1 (2017-07-31) (64-bit)
System: Windows 10 CU, SteamVR release version (i.e. not beta), HTC Vive

Steps:
1. Navigate to https://aframe.io/examples/showcase/helloworld/ (or any other experience)
2. Click enter VR
3. Observe that the camera Y position is roughly -1.6 when resting on the floor

Note this does not happen every time. Refreshing the page and trying again will get it back to normal behavior within a few tries. 
It sometimes happens on the very first try. It sometimes is OK on the first try, but will appear after refresh(es)
(In reply to william from comment #8)
> I'm still seeing this issue in 56.0a1 (2017-07-31) (64-bit)
> System: Windows 10 CU, SteamVR release version (i.e. not beta), HTC Vive
> 
> Steps:
> 1. Navigate to https://aframe.io/examples/showcase/helloworld/ (or any other
> experience)
> 2. Click enter VR
> 3. Observe that the camera Y position is roughly -1.6 when resting on the
> floor
> 
> Note this does not happen every time. Refreshing the page and trying again
> will get it back to normal behavior within a few tries. 
> It sometimes happens on the very first try. It sometimes is OK on the first
> try, but will appear after refresh(es)

I can reproduce it sometimes in 56.0a1 (2017-08-01) (64-bit). But if I create a new profile, I am no longer to reproduce it. Besides, it seems to only happen in A-Frame. Other demos from https://webvr.info/samples/ don't have this phenomenon.

William, can you help me check if creating a new profile or https://webvr.info/samples/ would solve the problem. Thanks.
Flags: needinfo?(william)
Thank you, Daosheng!

I can confirm the same experience as you reported:

1. I could not reproduce the issue in any webvr.info sample

3. After creating a new profile, I could no longer reproduce the issue in aframe examples
Flags: needinfo?(william)
Nice! Daosheng, Do you know the reason why deleting the profile fixes the issue? Thanks!
Flags: needinfo?(dmu)
After the discussion, we have figured out it is because the race condition problem when A-Frame uses offset data instead of the absolute position.
Flags: needinfo?(dmu)
Do you have an idea on how the profile and A-Frame applying offsets could be related?
Flags: needinfo?(dmu)
Go to about:config, set browser.tabs.remote.autostart.2;true seems could resolve this problem.
Flags: needinfo?(dmu)
You need to log in before you can comment on or make changes to this bug.