Zitat von »jeromebg«

Hi guys,
Just saw (late) that 3Dvista are providing a online service to download tours on the Oculus Go and be able to watch them offline. Their UI is clear and clean.
https://youtu.be/Kxo9o3e2uwE

Are they using a offline proxy or something to achieve that ?
Would love to be able to do the same with krpano tours of course ;)

I guess they've created a progressive web app: blog.heroku.com/how-to-make-progressive-web-app

Any news on controller support?

Zitat

Any news on controller support?

The next release has full VR-controller support (soon).

Hi,

just as note - the latest Oculus Browser update from yesterday has broken the VR rendering that browser.

It's a browser bug and reported here:
https://developer.oculus.com/bugs/bug/385828575401156/

As manual workaround for the moment add this line in the webvr.xml anywhere:


The next krpano release will have an internal workaround for that bug.

Best regards,
Klaus

Zitat von »klaus.krpano«

just as note - the latest Oculus Browser update from yesterday has broken the VR rendering that browser.

Boy, did it EVER break! This caused me to lose all my hair today. Thanks for supplying a quick workaround. Sadly it won't easily help tours deployed on client servers. I hope Oculus gets on top of this pronto.

Curiously, Pano2VR tours don't seem to be affected by the bug. Also noticed that tours displayed on the Gear VR Oculus browser work fine. Seems to me that they use to work with the Samsung browser on Gear VR but now you are asked for a view mode and none of them work with KRPano. FFR works but still has other problems.

Zitat

Curiously, Pano2VR tours don't seem to be affected by the bug.

I was also wondering why other software wasn't affected, but then I have checked the reason:

In WebGL rendering the 'canvas' (that's where all will be rendered into) needs to be set to a certain pixel-size.

In code that's just:

But then - the system is not always able to render in that size, e.g. older systems are sometimes limited to 2048x2048 and also many new systems, especially mobile systems, are limited to 4096x4096.

And when trying to set larger sizes then supported by the system (e.g. when using HiDPI or 'oversampling'), the browser is internally automatically capping/limiting that sizes.

But for setting-up the rendering viewport and the side-aspect the REAL rendering would be required!
Otherwise the rendering would be distorted when having a limited rendering size.

Therefore there is a browser API to get the real rendering size, e.g. just:
Only by using these 'real' sizes, a correct and undistorted rendering can be ensured in all cases!

And here the problem - since the latest Oculus Browser update, the drawingBufferWidth/drawingBufferHeight values are not updated instantly as they should - the browser updates these values with one frame delay! This is the browser-bug, no other browser has such bug.


So why is Pano2VR working? the VR output of Pano2VR is Three.js-based and Three.js is open-source and there can be seen that Three.js isn't checking for drawingBufferWidth/drawingBufferHeight sizes at all!

That means Three.js always assumes that the requested size would be supported by the system.
This can be done of course, but then would cause rendering problems when the requested sizes would get limited by the system.

That means the krpano code is the technically the more correct one and would normally support more usage cases... when there wouldn't be a browser-bug like this of course.


About the workaround: that xml code triggers additionally resize checks so that delayed change by the browser can be detected.

In the next krpano release no workaround will be necessary, there the drawingBufferWidth/drawingBufferHeight sizes are now tracked and checked every frame for changes. Then even such browser-bugs wouldn't matter anymore.

Zitat

Samsung browser on Gear VR but now you are asked for a view mode

So far I know the WebVR support need to be manually enabled in that browser. That 'view modes' are not for software, only for standalone images and videos.

Best regards,
Klaus

Yup! You clearly have a solid handle on the underlying software/hardware issues needed to make the magic happen. I dare say we all admire and appreciate that.

Hope the update of checking the drawingBufferWidth/drawingBufferHeight on every frame doesn't introduce too much processing overhead, but I suspect you have considered that already.

As for the Samsung browser, right again. I only activated WebVR on one handset long ago and that wasn't the one I picked up this last time.

<events webvr_onentervr="set(display.framebufferscale,0.9); delayedcall(0.1, tween(display.framebufferscale,1.0); );" />


i've pasted in your 'quick fix' above into the webvr.xml inside the 'plugins' folder but its not fixing the problem for me in my oculusGo.

i'm getting the VR split screen appearing in the left eye view only (nothing on the right side)

not sure what do do next now? have i missed a step?

i would very much appreciate any advice please

this is the tour in question.
https://www.historyrebuilt.com/wp-conten…r/VR/SD/SD.html

tell a lie ....

i think it might have done the trick.

sorry.


great job Klaus as always.

Hi,
I added these two lines in webvr.xml and uploaded to my server.
realwidth = gl.drawingBufferWidth;
realheight = gl.drawingBufferHeight;

Still the tour does not work in VR mode in my Oculus go. A can see the left/right picture but only by my left eye.

What to do to repair my tours for Oculus go??
SOLVED
( not only these two lines.....)

Technically more correct but not working is a disaster for Go users who love 360 VR. Please do everything you can to normalize the situation.
BTW no such problem manifests on my GearVR/Samsung S6 despite its running what is nominally the same browser.
Also note that Roundme.com does not have this problem.

Hello, i would like to know if it's possible to see layer on the oculus Go, i've tried some exemples but they disapear only on oculus GO...
regards

Zitat von »ChukA«

i would like to know if it's possible to see layer on the oculus Go

Nope. Just Hotspots.

Zitat von »klaus.krpano«

As manual workaround for the moment add this line in the webvr.xml anywhere:

Source code
1

Hi Klaus,
The fix is working perfectly for tours build with krpano pr16 version, but we are facing an issue with an older tour ( based on pr8). Even though the fix prevents the browser from crashing, it still doesn't render properly (not updating the view). Is there something different that can be done for older versions of krpano?
PS the tours where both created with panotour and edited with a lot of custom code.