krpano 1.19-pr14

  • 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 ?


    https://krpano.com/docu/xml/#display.autofullscreen

  • 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:

    To use it:

    Code
    <layer ... style="doubleclick"
             onsingleclick="trace(-single click-);"
             ondoubleclick="trace(-double click-);"
            />

    Best regards,
    Klaus

  • Hi Klaus,
    Please notice some break(); imperfection.
    Neither in if( ) nor in for( ); loop is it doing as expected. Am I missing something?

    (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:

    Code
    <hotspot name="hs1" url="skin/Rons.jpg" flying="0" scaleflying="false" zoom="false" distorted="false" alpha="1"  depth="off" />


    How it behaves in pr13

    How it behaves in pr14

    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: *wink*

    Quote

    Better, more natural non-distorted hotspot rendering for VR.

    Quote

    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

  • Quote

    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

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

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!