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.

1

Sunday, March 11th 2018, 10:33pm

Webvr not working with Chrome's latest updates

Hi Klaus,

I just wanted to let you know that currently krpano's webvr mode is not working with the latest chrome update on android (65)... have you noticed the issue ? If so do you know when and how there will be a fix to this :(

*confused*

Thanks

Aladdin !

2

Monday, March 12th 2018, 9:14am

Working fine on my Android with Chrome version 65.

3

Monday, March 12th 2018, 10:13am

Hi Ender,

I've tried Klaus's example on several android devices (Galaxy s7, HTC 10 ...)with the chrome browser 65, and the rotation via the gyroscope doesn't work



Could you please check this again , thanks !
https://krpano.com/krpanocloud/webvr/?v=119pr14

4

Monday, March 12th 2018, 10:51am

I do have the same problem (galaxy S7 too), everything looks fine until I try to use the gyroscope: it seems like I can look vertically but not horizontally (when I use the gyroscope). Works perfectly on my laptop, works perfectly with ALL other Android browsers I have.Version of Chrome : 65.0.3325.109

benji33

Intermediate

Posts: 244

Location: France

Occupation: Senior Software engineer

  • Send private message

5

Monday, March 12th 2018, 5:10pm


6

Monday, March 12th 2018, 5:39pm

I can look vertically but not horizontally (when I use the gyroscope)

Same issue using Chrome on Android with Google Pixel2. Tried with Firefox for Android and it works.

EDIT: Earlier convo in this thread with reply from Klaus: https://krpano.com/forum/wbb/index.php?p…&threadID=15981

This post has been edited 1 times, last edit by "thomasmcvea" (Mar 13th 2018, 12:25am)


7

Tuesday, March 13th 2018, 10:07am

Hi,

that's an Android Chrome 65 bug!
Google has broken it!

That doesn't effect only krpano, it affects all browser applications that are using the devicemotion or deviceoritention events.

A workaround is technically not possible, it's necessary to wait for Google for an update. So please make pressure there.


With Chrome 66 these events should work again, but in that version the Chrome browser changes also the gyro rotation values from radians to degrees!

Chrome was previously providing wrong values and fixed that now, but unfortunately without caring about backward-compatibility. That means all old code that was correcting the wrong Chrome values requires an update.

See here for more about that change:
https://groups.google.com/a/chromium.org…Es/jJuhTSEYCwAJ

The next krpano release (1.19-pr15) will have additional Chrome version checks for be able to provide support for old and new Chrome versions.

Best regards,
Klaus

8

Wednesday, March 14th 2018, 10:19am

Hi all,

Thanks everyone for your feedback and to klaus for the detailed explanation.

I've signaled the issue to chrome and even told them that firefox and safari are working to piss them off even more.

Any idea when pr-15 is rolling out ?

Thanks once again ;)

9

Wednesday, March 14th 2018, 11:01am

Hi,

Any idea when pr-15 is rolling out ?

I would say soon...
Actually I'm still working on several things that I would like to include in 1.19-pr15 but maybe I will forward them to pr16 and only that whats currently ready.

But first we need to wait for the fixed Android Chrome 65 release.
I would need to know if the 'radians to degrees' change will be in Chrome 65 or Chrome 66 to do the version check correct.

Here for the moment temporary updated gyro2.js and webvr.js plugin - they will assume that the 'radians to degrees' change will be in Chrome 66 and higher:
EDIT: updated plugins here:
Webvr not working with Chrome's latest updates


Best regards,
Klaus

Joel

Beginner

Posts: 8

Location: Innsbruck, Austria

Occupation: Interaction- and webdesigner

  • Send private message

10

Wednesday, March 14th 2018, 6:09pm

Thanks for the info and your work Klaus! I can confirm the problem. Tried 3 different Android phones with no problems on Chrome 64 and all three not working on Chrome 65 *cursing*

Regarding:
A workaround is technically not possible, it's necessary to wait for Google for an update. So please make pressure there.
I have clicked the star at the bottom of the issue saying "Vote for this issue and get email change notifications". Is there any other way we can make pressure?

11

Thursday, March 15th 2018, 12:51pm

Hi,

I found a workaround for Android Chrome 65:

Add these lines in the tour.xml after the vtourskin.xml include:

Source code

1
2
<plugin name="WebVR" mobilevr_sensor="0" if="device.android AND device.chrome AND device.chromeversion == 65" />
<plugin name="skin_gyro" sensor="0" if="device.android AND device.chrome AND device.chromeversion == 65" />

EDIT: here updated plugins without the need for xml changes:
Webvr not working with Chrome's latest updates


With that setting the webvr and the gyro2 plugins will use the 'deviceorientation' event instead of the 'devicemotion' event.

It will not work as good as with the 'devicemotion' event and due another Chrome bug it will be more jerky on some devices... but at least its better than nothing for the moment...

That workaround will be also included automatically in the next krpano release of course.

And I hope Google will start testing the gyroscope support after that fiasco (3 or more gyroscope related bugs within a short period!) with the next Chrome releases...

Best regards,
Klaus

12

Thursday, March 15th 2018, 5:18pm

You have made my day Klaus !!! Thanks a lot !


Do you know how we can avoid the jerky effect on some devices, do you have any idea on the devices that are more susceptible to be Jerky ?


Thanks once again Klaus !! *thumbsup* *thumbsup*

Joel

Beginner

Posts: 8

Location: Innsbruck, Austria

Occupation: Interaction- and webdesigner

  • Send private message

13

Thursday, March 15th 2018, 8:20pm

You have made my day also Klaus!! This was causing a major problem for one of our projects and I was waiting for Google to fix it, but without luck. I have just tested your fix and can confirm this works for Chrome 65.0.3325.109


Thank you Klaus for your support and solutions/work-arounds always!

14

Friday, March 16th 2018, 1:41am

Hi Klaus,
Do you have any tips on a workaround for tours built in Panotour?
Many thanks,
Alex

benji33

Intermediate

Posts: 244

Location: France

Occupation: Senior Software engineer

  • Send private message

15

Friday, March 16th 2018, 9:31am

Hi,

With this fix mobilevr_sensor="0" I've no result.
No move on vertical and horizontal axis with the fix and vertical only without the fix ! (tested with Huawei P8, LG G4 and Samsung S6)


With krpano 1.19pr14 webvr sample it doesn't work also.

My own code

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<plugin name="webvr" devices="html5" keep="true"
		url="webvr.js"
		mousespeed="0.00125"
		multireslock="true"
                fullscreen_mirroring="true"
                headtracking="true"
                friction="0.0"
                zoom="1.0"
		mobilevr_support="true"
		worldscale="1.0"
		oversampling="1.0"
		mobilevr_ipd="63.5"
		mobilevr_screensize="auto"
		mobilevr_lens_fov="96.0"
		mobilevr_lens_dist="0.60"
		mobilevr_lens_dist2="1.000|0.000|0.000|0.000"
		mobilevr_lens_ca="0.000"
		mobilevr_lens_vign="100"
		mobilevr_lens_overlap="1.0"
		mobilevr_wakelock="true"
		mobilevr_sensor_mode="3"
                mobilevr_sensor="0"
		mobilevr_autocalibration="false"
		mobilevr_touch_support="false"
		mobilevr_orientationlock="true"
		mobilevr_fake_support="true"
		vr_cursor="hotspot[vr_cursor]"
		vr_cursor_enabled="true"
		vr_cursor_onover="if(handcursor, tween(hotspot[vr_cursor].scale,0.4,0.1); vr_auto_click(get(vr_timeout)); );"
		vr_cursor_onout="tween(hotspot[vr_cursor].scale,0.3,0.1);"
		onavailable="webvr_onavailable();"
		onunavailable="webvr_onunavailable();"
		onunknowndevice="webvr_onunknowndevice();"
		onentervr="webvr_onentervr();webvr_portrait_mode_check(true);"
		onexitvr="webvr_onexitvr();"
		/>

This post has been edited 2 times, last edit by "benji33" (Mar 16th 2018, 9:42am)


16

Friday, March 16th 2018, 2:49pm

Do you know how we can avoid the jerky effect on some devices, do you have any idea on the devices that are more susceptible to be Jerky ?

That 'jerky effect' comes from that Chrome bug:
https://bugs.chromium.org/p/chromium/iss…d=819413&desc=3

That bug causes that the gyro data will be updated only 5 times per second instead of 60 times per second as normal. And that few data causes an imprecise and jerky control of course.

But the krpano gyro2 and webvr plugins are already compensating that problem a bit by interpolating the gyro data and so smoothing the movement. If you're interested you could try the setting sensor_mode="0" to see how bad only 5 updates per seconds really are ;-).

'Avoiding' that isn't possible because that's a core Chrome bug, but so far it seems with Chrome 66 that bug should be fixed.

17

Friday, March 16th 2018, 2:50pm

Do you have any tips on a workaround for tours built in Panotour?

I will post updated plugins in a few minutes, then you only need to replace the gyro2.js and webvr.js files (and clear the browser cache).

18

Friday, March 16th 2018, 3:07pm

My own code
<plugin name="webvr" devices="html5" keep="true"
url="webvr.js"
...
mobilevr_sensor="0"
...
First - it's a very bad idea to set sensor=0 for all devices and browsers!
It should be set only for Android Chrome 65! (see my example above)
But I will post shortly updated plugins, where all workarounds will be done automatically, then you only need to replace the plugin files.


With this fix mobilevr_sensor="0" I've no result.
No move on vertical and horizontal axis with the fix and vertical only without the fix ! (tested with Huawei P8, LG G4 and Samsung S6)
Second - this is not a 'fix', it's a workaround for a Chrome bug!

Here more information, maybe they help understanding:
  • The settings sensor="0" for the gyro2.js and the mobilevr_sensor="0" for the webvr.js means that these plugins will use the "deviceorientation" event instead of the "devicemotion" event.
  • That's because the "devicemotion" event is broken in Chrome 65 (only there).
  • So the workaround is to use the "deviceorientation" event instead (even when the tracking itself is not as good).

The 'sensor' settings were basically always there, but not documented (yet), because there should be normally no need to them.
I have added them now to documentation now - please see here for more information:
https://krpano.com/plugins/gyro2/#sensor
https://krpano.com/plugins/webvr/#mobilevr_sensor

So when sensor="0" isn't working in your case (I assume you're testing with Chrome 65) then something strange is wrong and I would recommend contacting the Chrome developers about that. From krpano side there is nothing here.

19

Friday, March 16th 2018, 3:10pm

Hi,

here updated gyro2.js and webvr.js plugin with automatic workarounds for Chrome 65 and higher:
krpano_gyro2_and_webvr_plugins_for_android_chrome65_and_higher.zip.zip

Just replace the current files and clear the browser cache.
Setting in the xml files are not necessary.

The new plugins are automatically using the "deviceorientation" event instead of the "devicemotion" event on Android Chrome 65 - and - for Chrome 66 and higher the 'radians to degrees' change is applied.

Best regards,
Klaus

benji33

Intermediate

Posts: 244

Location: France

Occupation: Senior Software engineer

  • Send private message

20

Friday, March 16th 2018, 3:36pm

Hi,

Of course the sample code above was designed for test only ;)
Yes it's a workaround and not a fix ... sorry for the mistake.
Thanks for the lesson about device motion/device orientation.

I've tested the 2 libs for Chrome 65 on 3 devices and it works with them. But your previous workaround post with only the XML edit wasn't working.

Thanks for this quick edit to partially solve the customers problem linked to the Chrome issue.