• Hey San7,

    This looks like a scope issue: while doing the tween on hs, the hs is overwritten (copy) with a new value and then that new value is tweened :)

    Maybe this could work (not tested):

    Code
    <action name="hid_show_hs" scope="local"  args="stat" > 
    		for(set(i, 0), i LT hotspot.count, inc(i),  	
    			copy(hs, hotspot[get(i)]);
    			if(hs.name == 'infohs', 
    				copy(hstotween, hotspot[get(i)]);
    				trace(hstotween.name);
    				tween(hstotween.alpha, get(stat));
    			);
    		);
    	</action>
  • Or even better is this, because then we are absolutely sure we tween the correct hotspot...

    Code
    <action name="hid_show_hs" scope="local"  args="stat" > 
    		for(set(i, 0), i LT hotspot.count, inc(i),  	
    			copy(hs, hotspot[get(i)]);
    			if(hs.name == 'infohs', 
    				trace(hs.name);
    				tween(hotspot[get(i)].alpha, get(stat));
    			);
    		);
    	</action>
  • Hi San,

    we used to add a for loop helper script to do, for example, tweening for hotspots and layers..in the past..because of this behaviour.
    remember HelperAction(get(hotspot[get(i)].name)); ? (or so..)
    'callwith' is your friend since some years *whistling*

    this works:

    Hope it helps
    Tuur *thumbsup*

  • Quote

    I ususally use San7 approach for looping through hotspts, but Tuur, your code looks so much clearner!

    yes but since the beginning of times doing a tween or so like that on a hotspot doesn't work in a for loop.
    My code is just the same but the new syntax is used.
    The callwith 'trick' worked already since it was available.

    We used to do, because of this, for example:

    Code
    for(set(i,0),i LT hotspot.count, inc(i),
    		if(hotspot[get(i)].tag == 'labrador',
    			Helper(get(hotspot[get(i)].name));
    		);
    );		
    		
    <action name="Helper">
    		tween(hotspot[%1].volume, 9);
    </action>

    Tuur *thumbsup*

  • yes but since the beginning of times doing a tween or so like that on a hotspot doesn't work in a for loop.
    My code is just the same but the new syntax is used.
    The callwith 'trick' worked already since it was available.

    We used to do, because of this, for example:

    Code
    for(set(i,0),i LT hotspot.count, inc(i),
    		if(hotspot[get(i)].tag == 'labrador',
    			Helper(get(hotspot[get(i)].name));
    		);
    );		
    		
    <action name="Helper">
    		tween(hotspot[%1].volume, 9);
    </action>

    Tuur *thumbsup*


    Tuur, thanks! I completely forgot that twin does not work in a cycle, my fault. *wacko*
    Yes, "tween" needs to be isolated

  • 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

  • Workaround:

    I have the feeling that doing too many things in the onviewchange() event is not optimal.
    (Escpecially in the beginning when not everything is initialized yet)


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

    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"

  • 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

  • I have the feeling that doing too many things in the onviewchange() event is not optimal.
    (Escpecially in the beginning when not everything is initialized yet)


    just FYI it is possible to make your code snippet much lighter *wink*
    you dont need get() in conditions or trace/debug(),
    also set(x,calc(1+2)); is the same as calc(x, 1+2);
    and set(x,get(y)); is the same as copy(x,y);

    Code
    <action name="pos_update" scope="local">
    	if(layer[text-pos].visible, 
    		roundval(layer[text-ath].text, view.hlookat, 2);
    		roundval(layer[text-atv].text, view.vlookat, 2);
    		roundval(layer[text-fov].text, view.fov, 2);
    	);
    </action>
  • I have a question about the display of obj.

    Is the error often on smart phones due to the size of the obj, etc?


    When an error is returned on a smart phone, is it because it is a preview version that it shows as a demo version?

    ---------------------------------------------------------------
    FATAL ERROR:
    A Browser with WebGL support is required!
    ---------------------------------------------------------------
    krpano
    demo version


    I am enjoying my first experience.
    Thank you very much.

  • Hi Klaus,
    Is it a bug if two hotspots in adjacent scenes, when placed too closely, do not work ideally or even poorly, resulting in vertical switching effect rather than horizontal effect? set3dtransition Is it a parameter setting issue?

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

    I would expect changes to apply without a delay after setting the layer to visible.

    Thanks for the example!
    Your expectation is right, this is indeed a bug.
    It's fixed now for the next release (soon).


    I have a question about the display of obj.
    Is the error often on smart phones due to the size of the obj, etc?
    When an error is returned on a smart phone, is it because it is a preview version that it shows as a demo version?

    Sorry, but I don't understand what you mean...


    Is it a bug if two hotspots in adjacent scenes, when placed too closely, do not work ideally or even poorly, resulting in vertical switching effect rather than horizontal effect? set3dtransition Is it a parameter setting issue?

    That's not directly a bug, that's the behavior defined the vtourskin.xml for 3d-transitions (see the skin_scene3dtransition action).

    When the vertical viewing angle towards the hotspot is very 'upright/steep', then the action assumes that the hotspot is on another 'level' and makes a 3D-move into that direction.

    To avoid this, change this line:

    Code
    if(v GT -50 AND v LT +50 AND caller.depth GT 120, set(v,0));

    to this:

    Code
    set(v,0);

    Best regards,
    Klaus

  • Hi, that error would only appear when the browser doesn't offer WebGL support (for some reason).

    klaus.krpano-san


    Thank you very much.


    It was displayed while prototyping a tour of obj files.

    Version of krpano,krpano-1.21_pre_2023-03-21.


    1.Does the WebGL error show demo?
    We have registered our license.

    2.It may be extremely rare, but the same error may occur in a tour of obj files.

    After the error message, another prototype tour of the same krpano version worked.


    Thank you all.

    Once discarded, I'm enjoying it in other prototypes *smile*

Participate now!

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