WebVR API was introduced over 5 years ago and gave developers the ability to launch VR content directly from the browser.
It has since been replaced by the newer WebXR API that we have awesome support in PlayCanvas (thanks to @max!) to give developers awesome VR and AR features in the browser.
Since WebVR is largely no longer supported by browsers, we have decided to remove WebVR support from the PlayCanvas Engine from 1.54.0 onwards.
Although I can understand the decision, I fear that this is quite problematic for my vr applications.
I currently use the old webvrpolyfill as a default solution on android and iOs devices alike.
The reason for that lies in my products, which are PWAs including VR-Experiences for walking tours,
targeting a broad range of devices and browsers.
And even on some newer android devices webXR often triggered a weird app installation, which led me to the decision to go back to the old webvr implementation and using the webvr polyfill as the overall solution.
See the basic project, which is the foundation for all of those projects:
https://playcanvas.com/project/860928/overview/spherical-viewer
I fear that with this upcoming update, calls like:
this.cameraEntity.camera.enterVr(() => { });
will no longer work.
But maybe someone could provide me a solution using the xr-api or maybe a kind of custom enterVr (re)implementation.
Again here the problem for me is to actively force the use of the robust webXRpolyfill or webVRpolyfill and preventing the potential problematic use of the browsers webXR implementation (for now)
Thanks again for your support.
That’s correct, these API’s will be removed on 1.54 release of the engine
What issues did you run into?
Thanks for your reply.
Well the key selling point of PWAs in my case is to not have to install any additional app and still be able to use it offline (with a Service Worker based cached version).
The problem was like a said, that the use of webXR with some android devices and chrome versions had the bad behavior of not falling back to the webXR Polyfill and instead triggering an app install (I think it was Google VR Services or similar) + often the vr stuff still didn’t work. I wasn’t able to “force” the use of the webXR Polyfill like I was with the webVR Polyfill, therefore I switched back to the webVR Version. I probably can stick with the old engine version (building from the editor) for now, but I probably need some solution for the future.
Again maybe that could be a simple solution as I only need a consistent way to call the webVRPolyfil or webXRPolyfill and not any “real” webVR functionality.
Ah, yes. That would be because WebXR requires the VR services from Google. @max, do you think there’s a way to fallback to polyfill for WebXR instead of attempting to download the VR services from Google?
Had a look at this and been struggling with this in that I can’t seem to force WebXR Polyfill onto the device without breaking it in some way.
I hacked the polyfill so that it always overridden the native API and just end with crashes or strange behaviour.
The polyfill doesn’t seem to work for iOS either which is a separate issue that I need to look into.
In your case @Rechi, I honestly don’t know what would the best route here would be as you could keep using an old version of the engine but I don’t know how long that will last for as an update to the Editor could potential break compatibility.
Thank you very much for your tries. For my current projects I will stick with the old engine version. In the long run an internal stereo viewer, simply based on device rotation without any vr/xr/polyfill should do the job, even with better customization:
Recently a pc user shared an initial solution with me, unfortunately he didn’t allow me to make it public available. But as soon as I find some time to get into shader stuff myself I will probably work on such a solution from scratch.
(Fixed the iOS polyfill on the projects now)