I've an issue with z-index and fullscreen.
In fact I use external div element out of the krpano div and I apply my own fullscreen treatment.
But since latests krpano version I've noticed that the z-index of the krpano element is applied to the highest zindex available (2147483647) and the others div cannot be displayed anymore with Android Chrome browser when rotating the screen (which apply the fullscreen event).
Is it a krpano or Chrome issue/feature ?
copyattributes() / PARENT
Hi
i played with copyattributes to copy all params from layer1 to layer2 and it turns out it has problems copying parent attribute: its value is correct in the debugvar but the layer doesn't show up in the parent element (it doesnt show up at all even if visible set to true)
Regards
I've an issue with z-index and fullscreen.
In fact I use external div element out of the krpano div and I apply my own fullscreen treatment.
But since latests krpano version I've noticed that the z-index of the krpano element is applied to the highest zindex available (2147483647) and the others div cannot be displayed anymore with Android Chrome browser when rotating the screen (which apply the fullscreen event).Is it a krpano or Chrome issue/feature ?
Nice thanks Jérome !!! I'll have a look.
ondoubleclick action for layer/hotspot
Hi Klaus,
Adding an ondoubleclick property for layer/hotspot as you did for events would be soooo nice!
regards
Hi,
copyattributes()
Please note that the copyattributes() when Flash viewer does not copy all attributes to the new destination (mainly numeric) e.g. width, height, ath, atv.
The workaround: device.flash only set() function.
i played with copyattributes to copy all params from layer1 to layer2 and it turns out it has problems copying parent attribute: its value is correct in the debugvar but the layer doesn't show up in the parent element (it doesnt show up at all even if visible set to true)
The copyattributes action was originally intended to copy attributes from custom elements.
When using it with layer or hotspot elements there are several problems - the action copies also 'state' attributes like loading, loaded and also some internal attributes - and additionally attributes that are predefined/build-in weren't copied in Flash because they are technically a special case there.
But to make that possible the next krpano version will have a special handling for this case - it will detect if the source is a layer or hotspot element and then skip these internal/state attributes and handle also the special Flash cases.
Best regards,
Klaus
Yes, that's the 'New Automatic Fullscreen Mode for Android when rotating the device to landscape mode' feature.
It was documented on the news page:
https://krpano.com/news/
and also in the release post:
krpano 1.19-pr14
krpano doesn't change the zindex in this case, it only uses the browsers fullscreen on landscape feature.
When using a custom fullscreen management outside of krpano that setting would need to be disabled.
Best regards,
Klaus
Adding an ondoubleclick property for layer/hotspot as you did for events would be soooo nice!
Here some code that will add 'onsingleclick' and 'ondoubleclick' events to layers or hotspots:
<style name="doubleclick"
downx="0"
downy="0"
clicks="0"
onsingleclick=""
ondoubleclick=""
onclick="doubleclick_style_onclick();"
/>
<action name="doubleclick_style_onclick">
inc(clicks);
if(clicks == 2,
set(clicks,0);
stopdelayedcall(doubleclickdetector);
if((((mouse.x-downx)^2 + (mouse.y-downy)^2)^0.5) LT (device.touch ? 10 : 2),
ondoubleclick();
,
onsingleclick();
onsingleclick();
);
,
copy(downx, mouse.x);
copy(downy, mouse.y);
delayedcall(doubleclickdetector, 0.3,
set(clicks,0);
onsingleclick();
);
);
</action>To use it:
<layer ... style="doubleclick"
onsingleclick="trace(-single click-);"
ondoubleclick="trace(-double click-);"
/>Best regards,
Klaus
thanks!
Hi Klaus,
Please notice some break(); imperfection.
Neither in if( ) nor in for( ); loop is it doing as expected. Am I missing something?
<action name="break_test">
<!-- OK -->
trace( before break);
break();
error(AFTER BREAK);
</action>
<action name="break_test_1">
<!-- HTML5 & Flash goes to ERROR -->
trace( before break);
if( true == true,
break();
);
error(AFTER BREAK);
</action>
<action name="break_test_2">
<!-- loop break (the next iteration...) -->
trace( before break);
for(set(i,0), i LE 5, inc(i),
trace(i);
if( i EQ 2, break(); );
);
trace( 'loop broken at ', i);
</action>(I use my test case in the onclick event of the contextmenu item but the same happens in html5 and flash viewer, too.)
Anyway thank you for your great work!
Pavel
Hi Klaus,
Please notice some break(); imperfection.
Neither in if( ) nor in for( ); loop is it doing as expected. Am I missing something?
i also never understood break();
long ago i tested it and i failed to use it to exit an action on a condition.
since then i never used it again.
something like this does not work as i remember...
<action name="test">
if(!condition, break());
... code block ...
</action>
Klaus,
There seems to be a bug with hotspot distortion in VR Mode in pr14. Distortion is always true. Here is the relevant code:
<hotspot name="hs1" url="skin/Rons.jpg" flying="0" scaleflying="false" zoom="false" distorted="false" alpha="1" depth="off" />Behavior is fine in non-VR Mode. Only VR Mode has the problem.
There seems to be a bug with hotspot distortion in VR Mode in pr14. Distortion is always true. Here is the relevant code:
That's not a bug, that's intended - here a quotes from the news page and the news post: 
Better, more natural non-distorted hotspot rendering for VR.
Improved non-distorted hotspot rendering for VR - the normal 'billboard' rendering method that is done on normal screens doesn't 'work' in VR. Now a rendering method will be used that will display the hotspots in an 'expected' way.
That means it's not the normal distorted=true mode, it is a special mode for VR (e.g. the hotspots don't scale with the fov like normal distorted hotspots do).
Please test and compare it in the headset and not on the desktop screen!
The new method should be much better - in VR it should be the equivalent to the normal non-VR viewing.
Best regards,
Klaus
The new method should be much better - in VR it should be the equivalent to the normal non-VR viewing.
I have looked at this in a headset and I'm not seeing it. I have updated the examples. When loaded, the image straight ahead has distorted="false". The version to the right has distorted="true". In v14 the two seem to behave exactly the same in VR Mode. The non-distorted image is locked to the background in VR mode and distorts with it, exactly like the distorted version. That is nothing like in non-VR Mode.
Why is this important? I use this to display still images in the headset. When doing that you want them to remain square to the screen when looking around, as they do in non-VR Mode, not distorting with the background.
Why is this important?
In non-VR mode the distorted=false hotspots are oriented to the flat screen surface - but in VR mode there is no flat screen surface. In VR such hotspots look like they would rotate by itself when you move the head around. So they will not remain 'square' anymore (when viewing in the headset).
But when keeping the hotspots oriented to the viewer (as distorted hotspots do) they have the same visual effect as the screen-orientation in non-VR. Now they will remain looking 'square'.
Btw - the more FOV the headset has (e.g. test with Vive or Rift if possible), the better that effect can be seen.
If really necessary I could add a setting for disabling that again, but I can't see any usage cases where this would be useful...?
Best regards,
Klaus
Klaus.. i noticed, too that hotspots in vr mode behave strange...
in my case i have info "i" icons without distortion
in non webvr they are oriented normally
but in webvr the lower center points to the "south-pole", which looks a bit strange
(also using a cardboard)
normal https://pasteboard.co/H9IrKyR.jpg
webvr https://pasteboard.co/H9IrxNu.jpg
best, index
Klaus.. i noticed, too that hotspots in vr mode behave strange...
What about when viewing them in a headset like Vive or Rift or GearVR?
Cardboard headsets typically have a much too few fov and are often not very well calibrated to be allow a judgement.
Vive or Rift or GearVR... i sadly dont have any of those...
in cardboard mode the effect is very strong as you see
to clarify, its not an urgent matter at all here.. just wanted to notice you about it
dunno if this is a problem of representation of distortion=false for headsets
but anyway in this case these rotations dont look optimal
OK. I've been working pretty hard on this, comparing the way non-distorted hotspots work in previous versions and v14 for the actual tour I am building. Got a Gear VR headset and a really good Cardboard goggle to test this fully. My conclusion......Klaus is right. Who knew!? V14 is better.
Still, ideal for me by a long, long shot would be a way to display a hotspot image so that it appeared to be -- and stay -- square to the phone. It would need the same pincushion distortion as a distorted hotspot to accommodate the goggle but no other 3D transform or rotation, just move in a 2D plane as you move your head. Is that possible, Klaus? It would make photo displays better and address index's button issue, I think.
Hello Klaus !
I've noticed that since the last Chrome update ( 65 ) the gyroscope is not working anymore on my Samsung smartphone.
http://www.prismamediaxrlab.com/tour-de-france/
Can you tell me if you already know this issue ?
thank you very much !
Don’t have an account yet? Register yourself now and be a part of our community!
