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):
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):
Or even better is this, because then we are absolutely sure we tween the correct hotspot...
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
this works:
<layer name="test1" type="text" align="top" x="-30" html="on infohs" onclick="hid_show_hs(1)"/>
<layer name="test2" type="text" align="top" x="30" html="off infohs" onclick="hid_show_hs(0)"/>
<hotspot name="infohs" type="image" url="gallery.png" />
<hotspot name="hsp_1" type="image" url="VT.png" ath="-30" />
<action name="hid_show_hs" scope="local" args="stat">
forall(hotspot,h,
if(h.name == 'infohs',
trace(h.name);
callwith(h, tween(alpha, *stat));
);
);
</action>
Display More
Hope it helps
Tuur
I ususally use San7 approach for looping through hotspts, but Tuur, your code looks so much clearner!
QuoteI 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:
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
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:
Codefor(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
Tuur, thanks! I completely forgot that twin does not work in a cycle, my fault.
Yes, "tween" needs to be isolated
Hi Klaus,
Is there a plan for GLTF file as a hotspot? (not threejs layer i mean) Thank you.
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:
<action name="skin_keydown_event">
if(
keycode === 80,
set(layer[text-pos].visible, true);
pos_update();
);
</action>
<events name="pos_update" keep="true" onviewchange="pos_update();" />
<action name="pos_update" scope="localonly">
set(global.layer[text-ath].text, calc(roundval(global.view.hlookat, 2)));
set(global.layer[text-atv].text, calc(roundval(global.view.vlookat, 2)));
set(global.layer[text-fov].text, calc(roundval(global.view.fov, 2)));
</action>
<style name="text-position-bold" type="text" keep="true" align="rightbottom" padding="7" bgcolor="0xffffff"
css="color: #003064; font-family: Arial, sans-serif; font-size: 16px; font-weight: bold;" />
<style name="text-position" type="text" keep="true" align="rightbottom" padding="7" bgcolor="0xffffff"
css="color: #003064; font-family: Arial, sans-serif; font-size: 16px;" />
<layer name="text-pos" type="container" keep="true" align="rightbottom" x="30" y="160" visible="false">
<layer name="text-ath" style="text-position-bold" x="48" y="80" text="0" />
<layer name="text-atv" style="text-position-bold" x="48" y="40" text="0" />
<layer name="text-fov" style="text-position-bold" x="48" y="0" text="0" />
<layer name="text-ath-label" style="text-position" x="0" y="80" text="ATH" />
<layer name="text-atv-label" style="text-position" x="0" y="40" text="ATV" />
<layer name="text-fov-label" style="text-position" x="0" y="0" text="FOV" />
</layer>
Display More
Kind regards,
Christian
Just a quick "i can reproduce" the scenario, so not something local.
Workaround:
<action name="pos_update" scope="localonly">
if (get(global.layer[text-pos].visible) == "true",
set(global.layer[text-ath].text, calc(roundval(global.view.hlookat, 2)));
set(global.layer[text-atv].text, calc(roundval(global.view.vlookat, 2)));
set(global.layer[text-fov].text, calc(roundval(global.view.fov, 2)));
);
</action>
Display More
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:
Code Display More<action name="pos_update" scope="localonly"> if (get(global.layer[text-pos].visible) == "true", set(global.layer[text-ath].text, calc(roundval(global.view.hlookat, 2))); set(global.layer[text-atv].text, calc(roundval(global.view.vlookat, 2))); set(global.layer[text-fov].text, calc(roundval(global.view.fov, 2))); ); </action>
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
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);
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?
A Browser with WebGL support is required!
this should only happen on old or very cheap mobiles
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:
to this:
Best regards,
Klaus
this should only happen on old or very cheap mobiles
Thank you very much.
It may be a rare bug in krpano.
We have tested it on PIXCEL 4a, 7, iPhoneSE and other smartphones.
Hi, that error would only appear when the browser doesn't offer WebGL support (for some reason).
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
Don’t have an account yet? Register yourself now and be a part of our community!