WebVR Playground is running well but my server version not

For a basic test of WebVR(XR) my playground is fine. In my iOS Safary and in Oculus quest:

But the same simple code in a plain html does not work. In Safari the rotation senors are not even requested, in Oculus it stays in 2D mode:

What did I do wrong?
There is no message in the browser log (except: Use of the orientation sensor is deprecated.)

xr requires https. make sure you serve your website using a secured connection

1 Like

Thank you! httpS was it, not only for WebXR but also vor WebVR access to device orientation.

The browsers block this access but do not make any output in the log?
(Well, I don’t have a log on VR/XR devices, only window.onerror. And there is no .onwarning in Javascript)
Could Babylon check and log it? May be not in the productive version but in the .max. version?

we can check for availability :slight_smile: And we do that. You probably got an exception (or a warning), but I think I will make it more prominent, as it seems to be a major issue with anyone starting with XR :slight_smile:

The browser’s XR namespace simply doesn’t exist when https is not available. the problem for us is that we can’t really know if the reason is that you don’t have https OR that you use a browser that doesn’t support it at all.

To check, if “https” is used, I searched it in the document.location for it.
If it is missing, a message “no WebXR” could be extended to “no WebXR, no HTTPS used!”

Drawing an error or using the log will not help stupid coders like me, testing in a VR/AR device without remote debugging. The only way seems to draw an alert(message).

The application code should handle both cases and avoid the babylon-alert this way.
To to so, Babylon could offer something like “checkReality()”, returning an structure of booleans:
https, webxr, webvr, touchcontrols, orientationcontrols (3df), positioncontrols (6df), handcontrolers, webAR
and the other optional functionalities of webxr.

I myselves consider to check https in index.html and restart it, adding this option
to overrool the “wrong” user URL.

MY way do solve user calls without HTTPS:

var httpsOk = window.location.protocol=="https:";
if(!httpsOk && window.location.host!="localhost")
     window.location = "https://"+ window.location.host + window.location.pathname;