Closed
Bug 1384865
Opened 7 years ago
Closed 7 years ago
OpenVR VRDisplay position is on the floor
Categories
(Core :: WebVR, enhancement)
Core
WebVR
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.
Comment hidden (mozreview-request) |
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → dmu
Assignee | ||
Comment 2•7 years ago
|
||
It looks like the game pose is the world space that we want. The Render pose is an object space of VRDisplay.
Assignee | ||
Comment 3•7 years ago
|
||
Using GetDeviceToAbsoluteTrackingPose has the same result as using WaitGetPoses() to get game poses. I prefer WaitGetPoses(), because WaitGetPoses() we always need it.
Comment 4•7 years ago
|
||
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 5•7 years ago
|
||
mozreview-review |
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
Comment 7•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/113b17f0f95d
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox56:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
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)
Assignee | ||
Comment 9•7 years ago
|
||
(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)
Comment 10•7 years ago
|
||
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)
Comment 11•7 years ago
|
||
Nice! Daosheng, Do you know the reason why deleting the profile fixes the issue? Thanks!
Flags: needinfo?(dmu)
Assignee | ||
Comment 12•7 years ago
|
||
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)
Comment 13•7 years ago
|
||
Do you have an idea on how the profile and A-Frame applying offsets could be related?
Flags: needinfo?(dmu)
Assignee | ||
Comment 14•7 years ago
|
||
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.
Description
•