Beiträge von klaus.krpano

Hi,

there are two bugs:

1. one bug in krpano - when using the alphachannel=TB/SBS setting with videos, krpano wrong sends an invalid value to WebGL until the video is loaded and ready...

2. and one bug in Chrome - even when the value is invalid, WebGL should silently ignore that invalid value and continue working. That means here the new Chrome release is buggy.

There is already a Chrome Bugreport about this: https://issues.chromium.org/issues/361823993
and it seems that bug was already fixed and there should be soon a new and fixed Chrome release.

The next krpano releases will have this also fixed.

As manual workaround it would be possible to replace this:
alphachannel="TB"
with:
onvideoready.addevent="alphachannel='TB';sourceheight/=2;"

This delays the alphachannel setting until the video is ready and so bypasses this bug.

Best regards,
Klaus

Just use: width="-60"

That’s 100%-60px

See here the note about negative values:

krpano.com - Documentation - XML Reference

Alternatively it would be also possible to use the childmargin settting on a parent layer:

krpano.com - Documentation - XML Reference

Example?

I'm my tests it works constantly...

Hi,

no, that's not normal - the view would be set.

If that doesn't work, something else must affect/change the view.

Best regards,
Klaus

Hi,

the <radar> element inside the Google- and Bing-maps plugins is not a normal krpano element, it's a kind of special element only for and inside these plugins...

Best regards,
Klaus

Hi,

here the Googlemaps plugin documentation:

krpano.com - Plugins - Google Maps

1) the <radar> there don't need to be 'added', that's just an element for settings and you can anytime set them, e.g.

layer[maps].radar.visible = true;
layer[maps].radar.size = 350;
layer[maps].radar.alpha = 0.33;

2) spots can be added using the plugin actions:

krpano.com - Plugins - Google Maps

e.g.

layer[maps].addspot(spot1, LAT, LNG, ...);
layer[maps].addspot(spot2, LAT, LNG, ...);

3) to set the map position:

layer[maps].setcenter(LAT, LNG); 

or animated:

layer[maps].panto(LAT, LNG); 

Best regards,
Klaus

Hi,

it might need some time until the plugin is loaded, so better call your plugin actions after the plugin is loaded, e.g.:

<action name="myction" scope="local">
    addplugin(myplugin); 
	set(plugin[myplugin].url,'%FIRSTXML%/myplugin.js');
	set(plugin[myplugin].keep,true);
	set(plugin[myplugin].onloaded,
       plugin[myplugin].load();
    );
</action>

Best regards,
Klaus

Yes, I had the same idea and that's already implemented in 1.22 (very soon).

Hi,

here another possibility as one-liner:

set(('button.'+attribute), value);

The ('button.'+attribute) gets evaluated as expression and its result then is used as argument for the set() call.

Notes the other suggestions from above - using array indices [] for addressing attributes doesn't work in krpano action code, that's Javascript syntax.

Best regards,
Klaus

Just as note - for future versions I have added now a request/plan for a hotspot setting to choose where to add/draw the SVG polygons (below CSS, above CSS or as extra sortable layer).

Mixing SVG and CSS hotspots is normally not possible.

The SVG layer is below the hotspots layer.

Although it would be possible by hacking the internal layer order to move the SVG layer on top...
E.g. here an action doing this:

<action name="svg_hack" type="js">
  if (caller.DATA.svgpoly)
    caller.DATA.svgpoly.parentNode.style.zIndex = 9999;
  else
    krpano.call("delayedcall(0,svg_hack())", caller);
</action>

Call it in the onloaded event of the polygonal hotspot:

<hotspot ... onloaded="svg_hack();" />

But I wouldn't recommend that because that code uses internal stuff and therefore could fail in future versions.

Sorry, I still can't reproduce it, in my case it looks identical each time...

It looks like the multiresolution loading just hasn't finished... (or stopped?)

Try adding this line in the xml to see the tile edges during loading:

<display wireframe="true" />

Okay, 'not clickable' by mouse - now I see the problem:

The 'vr_menu_bg' hotspot is a textfield and is rendered as HTML+CSS3D element by default - and these are above the WebGL content (the other hotspots) - and therefore blocking them from receiving mouse events.

But for fixing that, renderer="webgl" would need to be added either to the 'vr_menu_bg' hotspot or to the 'vr_menu_style' style, when adding to 'vr_menu_home' nothing will change.

The example will be fixed in the next release.
Thanks!

Best regards,
Klaus

Sorry I can't see or reproduce a problem..

Do you have step by step instructions?

Works normally for me and as the hotspot is an image, renderer=webgl is already the default behavior...

Do you have an example?

If "hs1" is the name of the hotspot, then better this way:

if (krpano.hoveringelement && krpano.hoveringelement.name == "hs1") ...

Hi,

that error indicates too much resource/memory need...

Check your project for everything that could eat up too much memory, e.g. large layer/hotspot images, too much videos or sounds at the same time...

That pano image itself shouldn't need much memory and cause the problem, but you could even try limiting its memory usage by trying a lower custom memory.maxmem setting:

https://krpano.com/docu/xml/#memory

Best regards,
Klaus

Please post a link to the example.

Hi,

that's a limitation of the current WebGL-based line rendering - the given coordinates are getting projected to a flat surface and that fails due the large spherical area they cover.

As workaround you could try adding renderer="svg":

<hotspot ... 
   renderer="svg"
>

Or add convert the spherical coordinates to 3D ones - a polygon with 3D coordinates is not limited or affected the flat-surface projection.

E.g. this could be done automatically using such action:

<action name="convert_to_3d_polygon" scope="local">
   for(set(i,0), i LT caller.point.count, inc(i),
       copy(p, caller.point[get(i)]);
       spheretospace(p.ath, p.atv, 1000, p.x, p.y, p.z);
   );
</action>

and

<hotspot ... 
   onloaded="convert_to_3d_polygon()"
>
   ...
</hotspot>

Best regards,
Klaus