I have noticed that as of yesterday, the VR viewer on mobile has changed significantly which has broke the graphics. Upon entering stereoscopic view, the scene is evidently rendered at much lower resolution and the edges on objects appear to be totally screwed (jagged). I have tested my own project and every demo on PlayCanvas on multiple Android mobile devices and the result is the same. I believe the Google VR services is not working, any insight on this? Thanks.
WebVR is currently an Origin Trial, which means that you have to apply for a token from Chrome to use the feature. The PlayCanvas Origin Trial Token has just expired which means WebVR on playcanv.as and playcanvas.com falls back to using the Polyfill.
I’ve applied for a new token and we’ll update it ASAP. (Usually takes a few hours)
Sorry for the inconvenience… hoping WebVR comes into proper Chrome stable soon
@dave looks great on our android devices in chrome. however we need to support the WeChat browser (it is the standard in china) and also of course iOS devices. the quality of the polyfill here is not suitable - is there another recommended fallback? is there a setting somewhere that i’m missing to improve this? or should i simply implement our own camera + control system?
cheers @yaustar! buffer scale is exactly what i was looking for but actually it seems performance is fine (maybe even better) using a two camera setup and gyro controls. this also gets us around the issue of the google vr services not being readily downloadable in china. anyhow will be keeping this tidbit safely tucked away
one remaining issue is how best to implement camera distortion when not using the polyfill. also am having issues with the camera stretching in landscape when not in fulscreen mode (i guess this is unrelated, am still learning the ins and outs of the engine).
for the first issue, there’s a cardboard-distorter here and a then a vr-camera bit here and also cardboard-vr-display here. it would actually be great to have an option NOT integrated with the engine for our use case. would appreciate additional feedback on this and the camera squishing / stretching from @dave or whoever else, cheers!
because it requests the user install google vr services and the app is for the chinese market (not available here). even if it were available, we wouldn’t want the user to be interrupted in this way -> for the purposes of this app a simple cardboard-like-viewer is all that’s required.
there were also some minor usability issues i noticed (maybe user error on my part), like on iOS the “settings” button does nothing, touch + mouse control issues (made desktop testing difficult), monoscopic view working the same on all platforms, etc. it’s certainly nice having these features integrated as part of the engine this way, but when something doesn’t work as desired or expected it would be nice to have a fully component based structure as a fallback that i can dig in to and tweak if necessary (it looks like that’s how this was previously implemented as well). the polyfill i guess is technically “open” but does not feel super nice.
@dave sorry my answer was a bit confusing. i wasn’t able to tick “enable vr” because for compatible devices it will request to install google vr services, and as i recall i wasn’t able to use the polyfill without this enabled. i’d wanted to ask if it would it be possible to default to your version of the polyfill and not touch any of the other native WebVR stuff, but then at a certain point it actually becomes more straightforward to use another engine (which has other benefits like making collaboration more straightforward too, as i’ve mentioned elsewhere in the forums). still really appreciate how helpful y’all are and the awesome work you do. will certainly continue to evaluate use on this and future projects