mrdoob
commented
5 years ago Should we close this in favor of #16649?
Closed mvilledieu closed 5 years ago
mrdoob
commented
5 years ago Should we close this in favor of #16649?
Hi,
The Magic Leap One will be adding support for both WebVR and WebXR very soon.
Issue:
Right now as you all know, if the implemented version of
WebXR APIdoesn't match the right version of the browser, it results in brokenWebXR APIcalls. Even if technically('xr' in navigator)does exist. The issue with that specific test happening in theWebGLRendererhttps://github.com/mrdoob/three.js/blob/880abcfb33801112211f8560d1910bbdc0246757/src/renderers/WebGLRenderer.js#L313
is that there is no way for a dev using a device that supports both WebXR and WebVR to specifically request the
renderer.vrto be initialized using theWebVRManagerand notWebXRManager. This becomes an issue when WebXR is constantly evolving and breaking changes are being introduced at every update like it currently is.The three.js WebVR examples could run fine in Chrome 73 using WebVR but are currently broken trying to run WebXR at first.
Example:
Currently, if WebXR is broken, and I decide to start the immersive session using WebVR rather than WebXR by for example commenting out the
if('xr' in navigator){}code in here:https://github.com/mrdoob/three.js/blob/93e72ba7b24958ddb0652bd33171edd14ed2d693/examples/js/vr/WebVR.js#L134-L197
The
renderer.vrhas at this point already been initialized with theWebXRManagerin place of the neededWebVRManagerbecause of that test:https://github.com/mrdoob/three.js/blob/880abcfb33801112211f8560d1910bbdc0246757/src/renderers/WebGLRenderer.js#L313
and causes the WebVR session to not start.
Propositions:
Devs should be able to specify if they want their renderer to be initialized with
xrorvr. This way they could be requesting the stableWebVR API, that will stay in the browser for a while before being entirely replaced, rather than getting stuck with WebXR just because their device supports WebXR in appearance.Potential solutions:
1 - Rather trying to initialize WebXR first if
('xr' in navigator)and WebVR if it is not the case. We could do the opposite, by first trying to initialized WebVR if'getVRDisplays' in navigator.Pros: WebVR is currently stable, not WebXR. Cons: At this point, people with devices that support both WebXR, and WebVR, would be stuck with WebVR, the same way they are currently stuck with WebXR.
2 - Make an exception for the MagicLeap device based on the user agent. We could test against the user agent and make sure while the
WebXR APIis not entirely stable to force running WebVR.Pros: Would always work running the stable
WebVR API. Cons: Dirty exception for one specific device, not sustainable if every company does that.3 - Refactoring the
WebGLRendererto be able to force initializing it using theWebXRManager, or theWebVRManager, it could be a parameter we pass to the Class. If no parameters are passed then we keep it the way it currently is.new THREE.WebGLRenderer({ xr: true });->if('xr' in navigator && xr) renderer.vr = new WebXRManager()new THREE.WebGLRenderer({ vr: true });->if('getVRDisplays' in navigator && vr) renderer.vr = new WebVRManager()new THREE.WebGLRenderer({ xr: true, vr: true });would return an error saying that we need to choose in between one or the other.new THREE.WebGLRenderer({ });if nothing is specified thenrenderer.vr = nullor we keep it the way it currently is, with the same test.We could then use that flag on the renderer in the
WebVR.jshelper to know what API to call.Pros: With this solution, you could make sure on devices that support both WebXR and WebVR, devs can decide if whether or not they use the nonstable
WebXR APIor decide to go with the stableWebVR APIwhile waiting for theWebXR APIto get more stable and work.I personally think the proposition 3 could be really nice and doesn't involve that much refactoring.
Please let me know if you have a better solution in mind.
Three.js version
Browser
With WebVR and WebXR both enabled.
Hardware Requirements (graphics card, VR Device, ...)
Magic Leap One.