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

Tuesday, November 12th 2019, 2:13pm

Oculus go problem. Incorrect tiles are displayed.

Hi!

Perhaps a device type "mobilevr" (oculus go) is not correctly detected.

When I viewing a virtual tour in the oculus go, he displays sets of tiles in multires mode

Source code

1
<image if="!webvr.isenabled">
, and not those that are created specifically for him

Source code

1
<image if="webvr.isenabled">
.

To exclude my possible mistakes, I checked the test scene by creating a tour with a standard droplet "MAKE VTOUR (VR-OPT) droplet".

Test confirmed suspicion. The Oculus Go displays tiles from the <image if="!webvr.isenabled"> section, not from the <image if="webvr.isenabled">.

If you manually erase the entire <image if="!webvr.isenabled"> (multires) section, more suitable tiles are displayed. The image does not suffer from moire, the display performance is quite smooth.

How to make it work by switching modes?
I tried using

Source code

1
<image devices = "mobilevr">
. Does not help.

Moire and slowdowns are very critical. How to get the krpano to display the correct sets of tiles in the oculus of go?

Scott Witte

Intermediate

Posts: 272

Location: Milwaukee, WI USA

Occupation: Professional Photographer

  • Send private message

2

Wednesday, November 13th 2019, 2:44am

Big Problem, But Easily Solved?

Did some testing on my Go and I think I know what you are seeing -- and I finally know why I'm seeing a significant performance problem as you start a tour.

The problem happens when you first enter VR mode. When you are in non-VR mode the multi-rez tiles are displayed. When you enter VR mode the entire multi-rez scene needs to fully render and only then do you switch to the VR tiles. This takes a long time, especially if using oversampling=2 and looking around during the rendering. In the Oculus browser, it is 7 - 12 seconds for me and significantly longer in FxR. And performance during that time is horrid! Once the VR tiles are in use performance is great.

Switching scenes in VR mode only shows the VR tiles. Transitions a quick and performance great. When you switch out of VR the multi-rez tiles again display.

To demonstrate this I put together a test case where I use tiles from different panos for preview, multi-rez and VR within a scene.

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
<scene name="Rockwell" title="Rockwell Statue" icon="" onstart="" havevrimage="true" thumburl="../../../greendale2/panos/Rockwell.tiles/thumb.jpg">
	<view hlookat="0" vlookat="0" fovtype="MFOV" fov="90" maxpixelzoom="1.0" fovmin="60" fovmax="140" limitview="auto" />

	<preview url="../../../greendale2/panos/Commercial1.tiles/preview.jpg" />

	<image if="!webvr.isenabled">
		<cube url="../../../greendale2/panos/Arrowwood.tiles/%s/l%l/%v/l%l_%s_%v_%h.jpg" multires="512,1024,2048,3840" />
	</image>

	<image if="webvr.isenabled">
		<cube url="../../../greendale2/panos/Rockwell.tiles/vr/pano_%s.jpg" />
	</image>
</scene>


Klaus - This is a critical problem that has been pissing off a couple of clients and causing me to lose hair. It may be related to a recent update in the Oculus Environment because the same thing suddenly started happening even with v1.19.16 in all browsers on the Go. But I think the solution could be quick and easy. Two ideas:

1) If you are in a mobilevr browser, only display the VR tiles (and previews, of course) even in a window. If someone really wants the desktop experience in a headset they can click the browser's "desktop mode" button.

2) When switching to VR mode immediately switch to the VR tiles, perhaps using the preview as an intermediary, if needed.

PLEASE fix this ASAP. It is business-critical for me.

3

Wednesday, November 13th 2019, 8:26am

My colleagues advised me on a simple workaround for the problem:

Source code

1
<events name="vr_enter_workaround" webvr_onentervr="loadscene(get(scene[get(xml.scene)].name), null, keepview, blend(0.5))"  keep="true" />




And it worked.
Work only on 1st scene %)

This post has been edited 1 times, last edit by "localhostroot" (Nov 13th 2019, 12:16pm)


4

Wednesday, November 13th 2019, 3:17pm

Hi,

to load the special VR images directly on startup on devices like the Oculus Go or Oculus Quest change the xml this way:

Source code

1
2
3
4
5
6
7
8
9
10
11
<scene ... havevrimage.mobilevr="false" havevrimage.no-mobilevr="true" ...>
  ...
  <image if="!(webvr.isenabled OR device.mobilevr)">
    ...
  </image>

  <image if="webvr.isenabled OR device.mobilevr">
    ...
  </image>
  ...
</scene>


Explanation: the device.mobilevr setting (new since 1.20) is true on these devices and so the VR images get loaded directly on startup even when not in VR mode. And by setting the havevrimage setting to false on these devices the reloading of the image will be skipped when entering VR mode, because it would be the same in this case.

Additionally attached here an updated vtour-vr.config to add these settings automatically on building:
vtour-vr-config.zip

Btw - oversampling=2 should be not necessary when using version 1.20, that version uses automatically a higher oversampling setting.

Best regards,
Klaus

5

Wednesday, November 13th 2019, 3:34pm

Hi,

one additional change - when using the desktop mode in the Oculus browser it's not possible to detect that the device is a 'mobilevr' device, so here small change in the vtourksin.xml to load the VR images faster:

Look for this line in the vtourskin.xml:

Source code

1
loadscene(get(xml.scene), null, MERGE|KEEPVIEW|KEEPMOVING|KEEPPLUGINS|KEEPHOTSPOTS|NOPREVIEW, BLEND(0.5));


and remove there the NOPREVIEW flag:

Source code

1
loadscene(get(xml.scene), null, MERGE|KEEPVIEW|KEEPMOVING|KEEPPLUGINS|KEEPHOTSPOTS, BLEND(0.5));


That avoids the waiting until the vr images are fully loaded.
For not available parts the preview pano image will shown instead.

Best regards,
Klaus

Scott Witte

Intermediate

Posts: 272

Location: Milwaukee, WI USA

Occupation: Professional Photographer

  • Send private message

6

Wednesday, November 13th 2019, 11:04pm

Success!

WOWZA, those changes make a world of difference. Sadly my hair may never come back but I should be able to keep some clients.

Not sure anyone has mentioned this before but Klaus.... Darn, you are good!

And big thanks for localhostroot. Without your original post I don't know how long it would have taken to figure this out.

As to oversampling=2 not being necessary, I'm not so sure. I did the comparison and on my Go aliasing is essentially eliminated and detail is noticeable improved. And I don't detect a performance hit. For me, oversampling=2 is still essential.