Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(WebVR) VR controller fly navigation & bug #940

Open
Joo918 opened this issue Feb 22, 2019 · 7 comments
Open

(WebVR) VR controller fly navigation & bug #940

Joo918 opened this issue Feb 22, 2019 · 7 comments

Comments

@Joo918
Copy link

Joo918 commented Feb 22, 2019

Hello,

I've implemented a new VR controller navigation method in the webVR branch's

src/util/VRControllerManager.js

where you can fly around by

  1. pointing at the direction where you want to go with the VR controller
  2. holding down on the trigger to move in that direction

This will let you look around independent of the direction you are moving. (aka strafing)
The VRControllerManager.js is very messy with all the debug code I wrote at the moment,
so I'll try to push it in after the code is clean.
I'll reply in this thread once I do.

Also during implementation, I noticed a bug.
While connecting the VR Controller after a "gamepadConnected" event,
a controller is connected only if the displayId of the controller matches the VR display's displayId.
However, I've noticed that the two never match.
(In my case, Oculus Go's displayId was 1 while its controller's displayId was 7)
I've currently disabled the displayId matching if-statement to work around the bug.
This isn't a problem for a single player environment,
but it certainly will be in a multiplayer setting where controller input should be bound to a specific display.
I suspect the mismatching is happening due to the controller's displayId initially being set before going into VR mode.
Does anyone know the exact cause of the bug?

@andreasplesch
Copy link
Contributor

Cool. I seem to remember that the new WebXR API has its own controller methods and recommends not to use the Gamepad API but I may be wrong. Anyways, it is still too early to switch from WebVR to WebXR.
You bring up a good point about multiple headsets and controllers potentially accessing the same scene. Let's find out what pure X3D offers in this regard.

@tsturm
Copy link
Member

tsturm commented Feb 26, 2019

@Joo918 It is really strange that your displayId's don't match.
I have tested it in Chrome with the HTC Vive, Oculus Rift, Oculus Go & the Google Daydream and
with all the devices the displayID of the controller(s) and the displayID of the HMD matches.

@Joo918
Copy link
Author

Joo918 commented Mar 1, 2019

@tsturm Really? I wonder if I did something wrong.. There are two Oculus Go controllers I have available and I tried pairing both to see if that made any difference. I still get mismatching displayIDs.

@andreasplesch
Copy link
Contributor

andreasplesch commented Mar 18, 2019

Using remote debugging with devtools I also get

Oculus Go's displayId is 1 while its controller's displayId is 7.

https://developer.mozilla.org/en-US/docs/Web/API/Gamepad/displayId#Browser_compatibility

says that this is only supported on daydream with chrome.

@Joo918
Copy link
Author

Joo918 commented Apr 1, 2019

Hi,
I want to push my update for the VR controller orientation based movement to the WebVR branch.
(change in src/util/VRControllerManager.js)
I tried to push and my access was denied.
Can I get help with this?

@jamesleesaunders
Copy link
Contributor

Hi Joo918,
You will not have permission to push directly to the repo (only the owners can do this).
You need to first fork the x3dom repo to your own area first.
Submit your change to your own repo and then raise a pull request for consideration to be pushed into the master repo.

For more info see:
https://guides.github.com/introduction/flow/

@Joo918
Copy link
Author

Joo918 commented Apr 1, 2019

Thank you for the guide! I'll try it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants