• @ piotr :
    are you really sure // ever worked on xml level ?
    i never used that outside of actions

    I use this type of comment for some time. Look here

    EDIT:


    I found it:

    Code
    There is now support for C / JS-style single-line // ... and multi-line / * ... * / comments in actions code.

    in actions code so in my case I had no right to work. *rolleyes*


    "Fix: Two '//' comments after each other weren't working correctly in some cases."

    P.S. You also disappeared the option to upload images on the forum?

    Piotr

  • Really cool features in this great udpdate. Can't wait experimenting with the Depthmaps.

    Unfortunatley, while updating some tours, i recognized that the VR Mode does not work for cardboard etc. it works awesome on Quest, but on Cardboard the distortion is weird. Also It does not recieve the right screen sizes (e.g. on Note8). Not only on my own tours, but also the samples.

    Has anyone also experienced it?

    Best Wishes and keep on hacking! :)

  • Unfortunatley, while updating some tours, i recognized that the VR Mode does not work for cardboard etc. it works awesome on Quest, but on Cardboard the distortion is weird. Also It does not recieve the right screen sizes (e.g. on Note8). Not only on my own tours, but also the samples.

    Has anyone also experienced it?


    I'm having the same issue on my Samsung S7, distortion seems ok but screen size is wrong, 3.8 instead of 5.1 ? tried on exemples on krpano website and on my tours also...


  • I'm having the same issue on my Samsung S7, distortion seems ok but screen size is wrong, 3.8 instead of 5.1 ? tried on exemples on krpano website and on my tours also...

    When i open it with an S7, it gives me the 5.1 Screen Size, but the distortions (for cardboard 1 and 2 are definitly different From the one i see in Google cardboard app. Testing with several further Phones and glasses, i always got a bad VR view. :(

  • Really cool features in this great udpdate. Can't wait experimenting with the Depthmaps.

    Unfortunatley, while updating some tours, i recognized that the VR Mode does not work for cardboard etc. it works awesome on Quest, but on Cardboard the distortion is weird. Also It does not recieve the right screen sizes (e.g. on Note8). Not only on my own tours, but also the samples.

    Has anyone also experienced it?

    Best Wishes and keep on hacking! :)

    Yes, i also have the same issue on my devices. All the Tours that i updated (and the samples also) don't look good in cardboard anymore (it gives me headache) :-/
    Are the new settings for Cardboard v1 & v2 the same as the previous Cardboard A & B ? Seems they are somehow changed, because in krpano 1.20 i see the distortion stereo mode in a "pillow" shape whereas before in krpano 1.19 it was square... *unsure*

    Remaining features are awesome!!! *thumbsup*

  • Hi again,

    and first a quick sorry for late responses - I was a bit busy with unexpected problems with the new license/upgrade system. It could have happened that the license codes have been sent delayed or multiple times. These problems should be fixed now, but if someone still hasn't received his license or problems with the license, please let me know.

    I will try now to answer as many questions as possible.

    Thanks and Best regards,
    Klaus

  • I have a few questions, does the 3d/depthmap feature support tiled images for gigapixel? If so, can the Depthmap tile and stream?

    Multiresolution together with depthmaps are basically supported, but in details it depends a bit - when using rendermode="depthmap" even gigapixel images would work, but the detection which tile is required currently works only for viewpoints near the original pano center. That means moving 3D around in a gigapixel and expecting to get the best tiles for the moved position doesn't work yet (although I'm working on that).

    With rendermode="3dmodel" the max. resolution is currently limited because of browser limitations. In that mode internally one single cubemap texture is used and the tiles are getting loaded into that texture. But the creation of large cubemap texture is unfortunately very slow in the browser, they internally clear the whole texture memory for 'security reasons' and for large textures this can take up to 500ms even on powerful devices, which is too long for smooth and uninterrupted transitions.

    That means for gigapixel panos with depthmaps, the rendermode="depthmap" setting might be the better one.


    Are there any options for nested gigapixel in this release?

    Not yet, the internal rendering engine would be already capable therefore, but I'm still not sure about higher-level APIs for using that. Currently I'm thinking about multiple <image> elements (with names) to define and control multiple pano-images for one scene...


    Klaus, what about some 'old timer' badge for old licenses?
    Would be very cool :) Current indication is quite shamy

    Do you mean the '(old license)' info inside the krpano log?
    There need to be some info somewhere, but I've tried to make it as invisible as possible, and it shows-up only in the krpano log itself, in the browser-console it wouldn't be shown (when using consolelog).
    Otherwise maybe see it as little motivation for an license upgrade ;-).


    Maybe I didn't understood something but I thought auto_oversampling which seems to be set to true by default would increase oversampling on devices like Oculus GO, but on mine oversampling is still set on 1

    The auto_oversampling tries to be a bit smart, when there is already an custom increased oversampling setting (e.g. from examples made with previous versions), it doesn't increase that setting even more until the manual oversampling setting is higher than the one that the auto_oversampling setting would use.

    You can try that interactively with the 'VR SETUP' menu - in the Oculus Go look at the bottom for a 'VR SETUP' hotspot, with it you can open the menu and there change the oversampling setting. One note here - in VR headsets with more buttons, there will no 'VR SETUP' hotspot, there instead one of the buttons can be used to open the menu.


    i recognized that the VR Mode does not work for cardboard etc. it works awesome on Quest, but on Cardboard the distortion is weird. Also It does not recieve the right screen sizes (e.g. on Note8).

    I'm having the same issue on my Samsung S7, distortion seems ok but screen size is wrong, 3.8 instead of 5.1

    When i open it with an S7, it gives me the 5.1 Screen Size, but the distortions (for cardboard 1 and 2 are definitly different From the one i see in Google cardboard app. Testing with several further Phones and glasses, i always got a bad VR view. :(

    The screensize is the most important setting for a correct VR display!
    When it's wrong please try to correct it manually before usage.

    krpano now uses the Cardboard device-database from here for getting the size for the device:
    https://github.com/immersive-web/webvr-polyfill-dpdb

    Then means when the size is wrong, the values in that database are wrong.
    To find out more, please post the user-agent-string and the correct size of your affected devices.
    Btw - even when it's a 'Samsung S7' there can be multiple different user-agents (e.g. depending on the country where sold).

    When the size is correctly set, the VR display itself should be the same as in Google Cardboard.

  • I think I found a BUG *confused*
    If I set:
    hotspot[...].prealign=true
    then
    set(image.prealign, '0|10|0');updatepos(true,true);
    And at this point this example stops working:


    That's not directly a bug, the dragable hotspots example itself just doesn't support hotspots with prealign=true.
    That example assumes that the ath/atv values of the hotspots and the pano-view are using to the same references.

    See the example source - it uses the spheretoscreen and screentosphere actions directly with the hotspots ath/atv values, but due hotspot.prealign=true these values are not the ones that will be used on rendering.

  • krpano now uses the Cardboard device-database from here for getting the size for the device:
    https://github.com/immersive-web/webvr-polyfill-dpdb

    Then means when the size is wrong, the values in that database are wrong.
    To find out more, please post the user-agent-string and the correct size of your affected devices.
    Btw - even when it's a 'Samsung S7' there can be multiple different user-agents (e.g. depending on the country where sold)


    Just checked the settings for my Samsung S7 G930F, it seems correct :
    {"type":"android","rules":[{"mdmh":"samsung/*/SM-G930F/*"},{"ua":"SM-G930F"}],"dpi":576.6,"bw":3,"ac":1000}
    So why krpano detects a 3.8" screen ? Result was correct with previous webvr plugin ?

  • The auto_oversampling tries to be a bit smart, when there is already an custom increased oversampling setting (e.g. from examples made with previous versions), it doesn't increase that setting even more until the manual oversampling setting is higher than the one that the auto_oversampling setting would use.

    You can try that interactively with the 'VR SETUP' menu - in the Oculus Go look at the bottom for a 'VR SETUP' hotspot, with it you can open the menu and there change the oversampling setting. One note here - in VR headsets with more buttons, there will no 'VR SETUP' hotspot, there instead one of the buttons can be used to open the menu.


    It's the way I understood that new setting ;)
    Just tried again your exemple : https://krpano.com/releases/1.20/examples/#webvr
    Which doesn't have any oversampling setting right ?
    When trying with Oculus Go the Oversampling is set to 1 instead of 1.4 ?
    I can increase manually and it works great, but that's not auto...

  • Question: When the text "old license" appears, does it mean that it is not updated? I paid for the update and this text appears to me. Or I'm wrong?

    Right, when there is the text 'old license' you're still using the old license. Please contact me my mail for more details and help.


    Just checked the settings for my Samsung S7 G930F, it seems correct :
    {"type":"android","rules":[{"mdmh":"samsung/*/SM-G930F/*"},{"ua":"SM-G930F"}],"dpi":576.6,"bw":3,"ac":1000}
    So why krpano detects a 3.8" screen ? Result was correct with previous webvr plugin ?

    There seems to be a 'dynamic resolution' problem' with Samsung devices - see here:
    https://github.com/immersive-web/…isplay/issues/7
    https://github.com/immersive-web/…-dpdb/issues/29
    https://github.com/immersive-web/webvr-polyfill/issues/327

    The Cardboard device database stores only the DPI for a device and the physical size will get calculated by the screen pixel-size the browser provides and that DPI value. Now the problem - when the device reports a wrong screen-size, that calculation fails of course.

    In the webvr plugin from the previous krpano version I was also using an own device-database where the physical size directly was stored and not just a scale factor, so a different screen sizes from the browser didn't matter. But as I don't have the resources to maintain a large database of Android devices, I have switched to the open Cardboard device database.


    It's the way I understood that new setting ;)
    Just tried again your exemple : https://krpano.com/releases/1.20/examples/#webvr
    Which doesn't have any oversampling setting right ?
    When trying with Oculus Go the Oversampling is set to 1 instead of 1.4 ?
    I can increase manually and it works great, but that's not auto...

    The most krpano examples are using the defaults, which are oversampling=1 and auto_oversampling=true.

    Even when auto_oversampling is enabled, the oversampling value itself keeps unmodified, only internally an additional scaling factor will be applied, but depending of the current oversampling value.

    Generally I would say the default values should be used, increasing oversampling even more wouldn't make much difference.

    Only the Drone Attack game is using auto_oversampling=false. That's because it's a fast game and there performance is more important than image quality.

  • The Cardboard device database stores only the DPI for a device and the physical size will get calculated by the screen pixel-size the browser provides and that DPI value. Now the problem - when the device reports a wrong screen-size, that calculation fails of course.

    In the webvr plugin from the previous krpano version I was also using an own device-database where the physical size directly was stored and not just a scale factor, so a different screen sizes from the browser didn't matter. But as I don't have the resources to maintain a large database of Android devices, I have switched to the open Cardboard device database.

    So it'll only work correctly when the devices run their maximum resolution (WQHD/2560x1440 in the case of the Galaxy S7).

    Am I right that at the moment there's no workaround and we'll have to wait for the Github repository to get updated?

  • So it'll only work correctly when the devices run their maximum resolution (WQHD/2560x1440 in the case of the Galaxy S7).

    Either that or manually set the screen-size in the VR SETUP menu. That means: touch once - touch on VR SETUP - and adjust there the screen-size.


    Am I right that at the moment there's no workaround and we'll have to wait for the Github repository to get updated?

    I will have a look, but ideally that database would get updated. I see now that the database supports rules for different resolutions, so for each resolution these Samsung devices eventually might provide an own scale factor would need to be entered there.

    As workaround it would be also possible to detect the affected devices manually in krpano code (by Actions code or Javascript code) and to set the screensize manually by using the mobilevr_screensize settings. I will provide an example for that.

  • Hi again,

    and first a quick sorry for late responses - I was a bit busy with unexpected problems with the new license/upgrade system. It could have happened that the license codes have been sent delayed or multiple times. These problems should be fixed now, but if someone still hasn't received his license or problems with the license, please let me know.

    I will try now to answer as many questions as possible.

    Thanks and Best regards,
    Klaus

    I paid on Sept 2nd but so far no new license code arrived wkaemena@mac.com

  • The Cardboard device database stores only the DPI for a device and the physical size will get calculated by the screen pixel-size the browser provides and that DPI value. Now the problem - when the device reports a wrong screen-size, that calculation fails of course.


    Ok my bad, my screen resolution was set to fullhd instead of WQHD for some reason, battery saving I guess...

    Even when auto_oversampling is enabled, the oversampling value itself keeps unmodified, only internally an additional scaling factor will be applied, but depending of the current oversampling value.


    Ok, I understand better now you say that the oversampling value itself keeps unmodified, thanx for your explanation !

Participate now!

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