I'm trying to replicate https://github.com/mrdoob/three.js/blob/master/examples/webvr_cubes.html in my https localhost environment but get an error navigator.xr.requestDevice is not a function on line 141 in https://github.com/mrdoob/three.js/tree/dev/examples/js/vr/WebVR.js when i enable WebXR Device API in my chrome browser (latest available--73).
Also none of the threejs webvr examples work after enabling WebXR Device API. They're all black screen.
--THREE.WebGLRenderer 103
I can confirm the error. It seems the example code does not reflect the current status of the WebXR Device API. three.js
will update its WebXR feature as soon as the API gets more stable, see https://github.com/mrdoob/three.js/issues/15393#issuecomment-469524019.
Ok Thanks... WebVR polyfill works great with threejs103... WebXR polyfill doesn't work good though..lots of jittering and flickering on meshes such as ring buffer geometry etc... closing this issue
I think this is a straight bug in Chrome which does not implement any version of XR correctly; it implements just enough to fool three.js WebVR into trying to use it. It could usefully be sidestepped in WebXR.js by replacing
if ( 'xr' in navigator ) {
with
if ( 'xr' in navigator && navigator.xr.requestDevice ) {
or similar.
Even though the bug is Chrome's, I suspect it has tricked enough people that it would be worth putting that extra code into three.js.
~~~
Related: I think there are enough differences between WebGL and WebXR that even where WebXR is working properly there should be some way explicitly to force WebGL and override automatic detection.
The WebXR implementation in Chrome is still being worked on.
I realize that, but meanwhile better protection from its current silly state in three.js would be welcome. I now know just not the enable it, but there must be many people who have wasted time being dumped into the problem. The suggested patch (or something along similar lines) will still allow three to use xr if there is any hope of its working. I know it is irritating putting in code to work around other people's errors, but ... worth it in this case?
I agree. Just spent about 2 hours trying to figure out why none of the samples on threejs.org worked but my local ones did.
Reason: Had WebXR enabled on Android Chrome. Works locally because WebXR is disabled in HTTP. Failed on threejs.org because it's served from https therefore the navigator.xr
exists but navigator.xr.requestDevice
does not.
A half line change seems worth it to prevent others from wasting hours of their day trying to figure out what's wrong.
Agreed! #16462 should solve this problem.
@greggman sorry about that! 馃檹
I'm currently getting this error on:
Warning: semi-related to this thread. Even though XR is still not stable Canary has removed WebVR from 80.xxx; (they head threatened to remove it from 79.xxx) My Canary updated itself this morning. Luckily I had squirreled away a 79.0.3942.0.
Most helpful comment
I think this is a straight bug in Chrome which does not implement any version of XR correctly; it implements just enough to fool three.js WebVR into trying to use it. It could usefully be sidestepped in WebXR.js by replacing
if ( 'xr' in navigator ) {
with
if ( 'xr' in navigator && navigator.xr.requestDevice ) {
or similar.
Even though the bug is Chrome's, I suspect it has tricked enough people that it would be worth putting that extra code into three.js.
~~~
Related: I think there are enough differences between WebGL and WebXR that even where WebXR is working properly there should be some way explicitly to force WebGL and override automatic detection.