Posts by ctt360

    Sorry, I can't reproduce that... did the same Linux tests now and in my case all mouse button values are correct...

    Hi Klaus,

    I uploaded my test case: https://36o.de/test/krpano-1.22.3-mouse-button/

    My console output:

    log.png

    The first click is a left click, the second click is a right click and the third click is a middle click. "mouse.button" is correct for both left and middle click, but not for right click.

    "mouse.leftbutton", "mouse.middlebutton" and "mouse.rightbutton" are always "false". However, I just checked this with krpano 1.21 with the same result. This might be related to the fact that I don't actually trigger those clicks with a mouse device, but via touchpad gestures. Not sure, if this is the intended behavior.

    Kind regards,
    Christian

    Hi Klaus,

    there was an issue with the right mouse button click on Mac, which was fixed in 1.22.3 (report). It still doesn't work correctly for me on Linux (tested with Chromium 131.0.6778.139 and Firefox 133.0.3 on Ubuntu 22.04). "mouse.button" returns 0 and "mouse.rightbutton" returns false on right click. It does work as expected on Windows 11 for me.

    Kind regards,
    Christian

    Hi Klaus,

    I'd like to suggest to also convert uppercase characters to lowercase characters (when the filterbasename setting is enabled), as those may also cause problems.

    Although uppercase characters are added to the tour.xml file (scene name="a_B_c"), they are converted to lowercase characters when they are loaded by krpano (scene name="a_b_c"). This can lead to situations where a value like krpano.get('global.xml.scene') can't be reliably used to trace back to the source XML element. Granted, this might be a minor edge case, but I do run into this problem semi-regularily in our software and need to remind myself to convert certain values to lowercase when comparing them with other values.

    Kind regards
    Christian

    Hi Klaus,

    when trying to start "krpano Tools.exe" on a Microsoft Surface device with Windows 11 (new device, so it is a fresh installation), the following error message is displayed:

    Code
    krpano Tools.exe - Einsprungpunkt nicht gefunden
    
    Der Prozedureinsprungspunkt "StackWalk64" wurde in der DLL "C:\...\krpano-1.20.11\nw.dll" nicht gefunden.

    The same error message is shown when trying to start krpano 1.22.2. I was just trying out different krpano versions to see, if they work.

    ----

    StackWalk64 seems to be contained in the DbgHelp library, which can be obtained by installing the latest Windows SDK according to this article. Alas, the problem was not solved by installing this SDK (I installed the full SDK, not only the debugging portion). I guess, dbghelp.h is not the same as the Debug Help Library.

    As I'm not proficient in Windows applications development, I can only guess that the StackWalk64 method mentioned in the error message is either contained in another unknown library, which is not installed by default on Microsoft Surface devices, or there is another reason why this method can't be called correctly. Either way, I'm not sure what else I can do to make it work.

    Any ideas on how to solve this are greatly appreciated.

    Thank you and kind regards

    Christian

    Hi Klaus,

    the action "set3dtransition" has an optional "hlookatoffset" option. It would be nice to also have such an option for the vertical axis. For some panos, we set the "vlookat" attribute of the "view" tag to capture the most important part of the image (e.g. looking upwards to see more of a building from the outside). When the user moves to the next scene (to the inside of the building), we need to correct the vlookat mostly to "0", but it might also need to be set to another specific value depending on the scene.

    The same applies to the "fov" value: When the user zooms into a pano and then moves to the next scene, we want to reset the "fov" value of the new scene to a specific value under some circumstances.

    Right now, we solve this using a tween starting halfway through the 3d transition. But this doesn't look very nice and sometimes results in a weird bouncing animation. It would be better to call "set3dtransition" with a "vlookatoffset" and a target "fov" that is applied to the new scene before the transition starts.

    Thank you and kind regards,
    Christian

    Workaround:

    Nice workaround, it does seem to work reliably this way.

    ----

    Hi, most likely when "visible" is disabled, the layer is ignored. Manage "alpha" instead of "visible"

    set(layer[text-pos].alpha, 1);
    <layer name="text-pos" ... visible="true" alpha="0"

    It does make sense that invisible layers are ignored. But I would expect changes to apply without a delay after setting the layer to visible.

    Your solution does seem to work, but you'd need to also update attributes like "capture", "handcursor" etc. on the container and/or its child elements.

    ----

    The code example might not be the best solution, but it's a snippet of legacy code in our app that worked as expected in older versions. I can easily refactor our own code, but this would not be possible with encrypted third party plugins.

    Thank you for your input!

    Kind regards,
    Christian

    Hi Klaus,

    I noticed, that the text of invisible layers is not reliably updated, even after they switch to being visible. Please see this test case:
    https://36o.de/test/krpano1.21-text-update/

    After loading the tour, move the panorama at least a little bit, then press the character "p" on your keyboard. This will show the current numbers for hlookat, vlookat and fov in the bottom right corner of the tour. However, most of the time the number for ath (hlookat) will not be displayed. Sometimes, two or all three numbers are not displayed. When you start moving the panorama again, the numbers are usually displayed after a few seconds.
    You can see the behavior in action in this video: https://36o.de/test/krpano1.21-text-update/video.mp4

    If you can't immediately reproduce this, reload the tour and try it again. It doesn't seem to happen 100% of the time, but it does happen often for me in Chromium (111.0.5563.64) and Firefox (111.0.1) on Linux.

    This is the complete code to reproduce the issue:

    Kind regards,
    Christian

    Hi Klaus,

    in 1.21 (2023-03-16) some properties from the 'css' attribute are not applied to text layers when the 'cssstyles' attribute is set (it worked as expected in 2023-02-09). Some properties like 'background-color' work, but others like 'color', 'font-family' and 'font-size' are filtered.
    Please see this test case: [redacted]

    This is the complete code to reproduce the issue:

    Kind regards,
    Christian

    Hi Klaus,

    please see this test case: [redacted]

    The first two scenes are taken from your apartment demotour, but I added an hlookatoffset to the onclick action when walking from the entrance to the bedroom ("scene3dtransition(br, 90);"). The transition works as expected.

    In the next two scenes (016 and 017), the "prealign" attribute is used in the <image> tag. When you walk from scene 016 to scene 017 (via the white arrow; hlookatoffset is set in the onclick action: "scene3dtransition(scene_017, 90);"), you will notice the panorama abruptly switching its viewing direction before the transition starts. When you walk back from scene 017 to scene 016 (hlookatoffset is not set in the onclick action: "scene3dtransition(scene_016);"), the transition works as expected.

    When I remove the "prealign" attribute from scene 016, the transition between scene 016 and 017 works as expected as well. But walking back from scene 017 to scene 016 seems to be off now, as I kept the "prealign" attribute in scene 017. I need to remove the "prealign" attribute from all scenes for all transitions to work as expected.

    May I ask you to check, if this is a bug in the pre-release version?

    Kind regards,
    Christian


    Sorry, I can't reproduce this...
    Do you use version 1.21?

    Hi Klaus,

    yes, I use version 1.21. After some more testing I have now isolated a test case, please see [redacted] (view-source:[redacted])

    Executing this command via the console will only display the blurry preview image:

    Code
    krpano.call('change_scene_localonly("scene1");');

    This command works as expected:

    Code
    krpano.call('change_scene_local("scene1");');

    "scene1" is from an older project that I tried to upgrade to krpano 1.21 and it looks like this:

    I also added a "scene2" to the test case that works as expected with both actions ("local" and "localonly"). This is a newly created scene using the krpano tools 1.21.:

    So I guess this has something to do with backwards compatibility. Not sure, what your policy is in this case, as krpano 1.21 is expected to break some things anyway and we might need to simply regenerate all scenes when upgrading older projects.

    Kind regards
    Christian

    Hi Klaus,

    I noticed a strange behavior when calling "loadscene" inside an action with its scope argument set to "localonly". This action code will only load the preview image of the new scene (plus its hotspots etc., but the pano will stay blurry):

    Code
    <action name="change_scene" scope="localonly" args="new_scene">
        loadscene(get(new_scene));
    </action>

    When I change the actions scope to "local" the full pano image gets loaded as expected:

    Code
    <action name="change_scene" scope="local" args="new_scene">
        loadscene(get(new_scene));
    </action>

    My guess would be that the "loadscene" action inherits the scope from my action, but doesn't use the global object to access certain variables and fails silently. This might be related to this change from the release notes:

    Quote

    Fix: When a loadpano/scene/xml action was called from a localscope action, the xml parsing could wrongly write some parsing results into the localscope.

    Is this behavior intentional?

    Kind regards
    Christian