You are not logged in.

Dear visitor, welcome to krpano.com Forum. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Posts: 40

Location: Tilburg, The Netherlands

  • Send private message

81

Wednesday, June 5th 2019, 9:44am


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

a.pu

Trainee

Posts: 73

Location: Default city, Russia

Occupation: Vtour dev, design, UX and photography

  • Send private message

82

Tuesday, June 25th 2019, 10:56am

Any news on controller support?

83

Wednesday, June 26th 2019, 4:22pm

Quoted

Any news on controller support?

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

84

Tuesday, July 16th 2019, 5:43pm

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:

Source code

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


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

Best regards,
Klaus

Scott Witte

Intermediate

Posts: 252

Location: Milwaukee, WI USA

Occupation: Professional Photographer

  • Send private message

85

Wednesday, July 17th 2019, 1:42am

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.

86

Wednesday, July 17th 2019, 10:51am

Quoted

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:

Source code

1
2
canvas.width  = targetwidth;
canvas.height = targetheight;

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:

Source code

1
2
realwidth = gl.drawingBufferWidth;
realheight = gl.drawingBufferHeight;
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.


Quoted

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

Scott Witte

Intermediate

Posts: 252

Location: Milwaukee, WI USA

Occupation: Professional Photographer

  • Send private message

87

Wednesday, July 17th 2019, 5:28pm

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.

This post has been edited 1 times, last edit by "Scott Witte" (Aug 6th 2019, 5:49pm)


simon64

Beginner

Posts: 39

Location: uk

Occupation: architectural illustrator

  • Send private message

88

Thursday, August 8th 2019, 6:20pm

quick fix not working for me

<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



*sad*

simon64

Beginner

Posts: 39

Location: uk

Occupation: architectural illustrator

  • Send private message

89

Thursday, August 8th 2019, 6:36pm

tell a lie ....

i think it might have done the trick.

sorry.


great job Klaus as always.

martyhr

Intermediate

Posts: 329

Location: CZ

  • Send private message

90

Friday, August 16th 2019, 6:21pm

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.....)

This post has been edited 1 times, last edit by "martyhr" (Aug 16th 2019, 9:19pm)


Posts: 67

Location: Philadelphia, Pennsylvania

Occupation: Retired S/W engineer

  • Send private message

91

Tuesday, August 20th 2019, 11:45pm

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.