HUD - How to move FAST

[hectic1]

Hello, i'm learning LSL by trying to make a custom texture+color+sheer+materials HUD. I'm doing a decent job so far I think, and the forum has already helped me with Chimera's Color PIcker, the code of which I have modified and embed into this custom HUD.

My current question is about minimizing/restoring the HUD and all its children. I have already implemented that, but the effect is not rapid as in other HUDs i have seen and/or used. In my HUD the min/restore button is the root prim, and the way i move it off and on screen is via this function I have coded:

integer g_is_hud_minimized = 0;
<snip>
/* ----------------------------------------------
 * Move all children of a prim (specified by link) by the given offset.
 */
MoveLinkChildrenByOffset(integer link, vector offset)
{
	list params_lst = [];
	vector local_pos;
	integer i = llGetNumberOfPrims();
	while (i > link ) {
		params_lst = llGetLinkPrimitiveParams(i, [PRIM_POS_LOCAL] );
		local_pos = llList2Vector(params_lst, 0);
		llSetLinkPrimitiveParamsFast(i, [PRIM_POS_LOCAL, local_pos + offset] );
		--i;
	}
}
<snip>
if (g_is_root_min_restore && touched_link == LINK_ROOT) {
  if ( g_is_hud_minimized ) {	// show the HUD
    MoveLinkChildrenByOffset(LINK_ROOT, -1*POS_OFFSET);
  }
  else { 	// hide the HUD
    MoveLinkChildrenByOffset(LINK_ROOT, POS_OFFSET);
  }
  g_is_hud_minimized = !g_is_hud_minimized;
}

So the idea is that that everything but  the root prim is moved by the given offset when the root is touched. This works, but I can literally see the children of the HUD moving off and on screen one by one, especially when the HUD contains lots of children (around 60 atm). I did try hidding them via alpha = 0.0 prior to moving the HUD off screen, and then show them back via alpha  1.0 when moving the HUD on screen, and it did get a little better, but nowhere near the rapid effect i see with other HUDs (plus, i don't really want to apply alpha =1.0 to all children when showing the HUD, cause some of them may initially be semi-transparent... and using a loop like the one above for their initial alpha, would slow things even more ).

I understand the problem is due to the loop that visits all children and process them one by one, but I wonder how others do it and they have their HUDs moving off and on the screen in a blink of the eye. And i'm talking about those ppl who don't just rotate the HUD, but actually move it off screen (like Catwa heads HUDs for example). I can tell they move it off screen, cause i see them when I edit their HUDs and then use the mouse-wheel to shrink the visible part of the screen.

Any help is greatly appreciated.

 

[Innula Zenovka]

A simpler way to  do it may be to reposition the root prim so that you can move the whole linkset far enough so that it's all offscreen except for the root prim. Then you can use llSetPos().

However, if you  want to do it the long way round, then you can do something like this:

vector vOffset = <0.0,0.5,0.0>;//or whatever
default
{
    state_entry()
    {
    }
    touch_start(integer total_number)
    {
        integer max = llGetNumberOfPrims()+1;
        list temp;
        integer counter = 2;
        do {
            vector vPos = llList2Vector(llGetLinkPrimitiveParams(counter,[PRIM_POS_LOCAL]),0);
            temp +=[PRIM_LINK_TARGET,counter,PRIM_POS_LOCAL,vPos+vOffset];
        }
        while (++counter < max);
        llSetLinkPrimitiveParamsFast(LINK_ALL_CHILDREN,temp);
        vOffset *= -1.0;
    }
}

 

[hectic1]

Wow, that was plain awesome! Tried it and it worked pretty good (so that's what PRIM_LINK_TARGET does :))) Ty so much!

I still can see it moving off and on screen, but this time is really fast, since llSLPP is only called once! I will also try the other suggestion, moving the root, but I'm not sure i totally got it. When we move the root prim, its children are automatically moved along, keeping their relative positions?

Edited April 4, 2017 by hectic1

[Innula Zenovka]

Yes, if you move the whole linkset with llSetPos called by a script in the root prim, that moves the children along too, retaining their relative positions.

[hectic1]

It worked too, and it's less memory intensive, TY!

[Xiija]

it may also be that some of the HUDs that appear to move so fast are setting the alphas

to zero before moving, so that the movement is not seen at all?

 

 

[hectic1]

I don't think so, because the Catwa heads HUDs which i used as an example above, are visible when editing them and then shrinking the screen viewing part via the mouse-wheel.

[Love Zhaoying]

It's possible they also shrink the size of the HUD quick enough (instead of just moving) that it appears to move even faster. 

[Berksey]

That's a really pretty script, thanks for sharing it!

Moving the linkset is fast enough it's practically instantaneous. Good stuff.

On a side note, having the same texture on both sides of the root prim, and if you've positioned it all so that the root prim seems not to move when it happens, I'm wondering if you can simply flip the entire thing on its Z axis, and achieve the same effect...? The button would appear the same, and the HUD would effectively vanish..., right?

Edited April 4, 2017 by Berksey

[hectic1]

I took a closer look at the Catwa HUD, what they do is quite similar to what Innula suggested (that is moving the root of the HUD off screen) but they use rotation instead.  There is quite a gap between the root prim (the min/restore button) and the rest of the HUD. When minimized, the root prim is shown inside the visible part of the screen and the rest of the HUD is located above the visble top (edit the HUD and use the mouse-wheel to see it) but it is rotated. When you click on the root prim, the whole thing gets rotated again (apparently with a reversed angle) so now the root prim goes over the visible top of the screen (they make it invisible too), and the rest of the HUD shows up in the visible part of the screen.

Apparently, the diff between this and moving the HUD, is that with rotating it, both the root and the rest of the HUD appear at the same location when they are shown.

This made me take a look at the llSetRot() wiki, expecting it to work like llSetPos(), meaning that by rotating the root prim, then all children will be rotated accordingly keeping their relative positions. Unfortunately, I got really confused by the wiki.

There is a note stating: "If the prim is attached, then this function offsets the rotation by the avatar's rotation.". Then there is an example for rotating the root prim, but it's noted that "it won't work on child prims if the root is rotated.", and then there are these 4 snippets:

//-- These correctly set a global rotation for the root prim in all scenarios
llSetLocalRot( rot )
llSetPrimitiveParams( [PRIM_ROT_LOCAL, rot] )
 
//-- These correctly set a global rotation for a child prim in all scenarios
llSetLocalRot( rot / llGetRootRotation() )
llSetPrimitiveParams( [PRIM_ROT_LOCAL, rot / llGetRootRotation() ] )

It must be my inexperience, but i don't really get what is going on. But if i got it right, we can't just llSetRot() the root prim, like we did with llSetPos(), is that true?

On a side note, when moving everything but the root prim, like I tried to do it initially (and Innula brought up the great PRIM_LINK_TARGET implementation) its easier to make it never expose its hidden part (the one that is off screen), even if the user manually moves it say to the opposite corner of the screen, cause according to the PRIM_POS_LOCAL documentation, when applied on a HUD, the value 1.0 in the pos vector translates to the corresponding dimension of the visible screen. Also it doesn't really matter where the HUD is initially attached on the screen. However, its is considerably slower compared to moving the root (and judging from Catwa's HUDs, compared to rotating too), especially for HUDS having like 300 buttons on them (like Catwa's HUDs).

Any pointers on rotating FAST the root prim and have its children follow, will be more than welcome

Edited April 5, 2017 by hectic1

[Rolig Loon]

When in doubt, experiment.  You are more likely to learn unexpected things by making mistakes than by following someone else's cookbook instructions are getting their answer to work the first time. And consult handy references like the table at http://wiki.secondlife.com/wiki/Rotation#Single_or_Root_Prims_vs_Linked_Prims_vs_Attachments

With any linkset, anywhere, if you rotate the root, the children will follow.  Since a HUD is an attachment, either llSetRot or llSetLocalRot or their equivalents with SLPPF will rotate the linkset the way you expect.  Just try it and see.

[hectic1]

Ty for the answer Rolig, and for the link!

Ofc I'm trying things out.. that's all i do actually. But sometimes when there's so much stuff going on and/or you are tired or frustrated due to things not working as u expect, then a little help sparing you the trouble of hunting wiki links one after the other, or trying to digest notes, examples and snippets that don't make much sense to you at that given moment, is like a god-sent bless. Especially when you are trying to learn a new language, the docs of which are not exactly organized perfectly or very easy to discover... and all that assuming that you know what you are looking for, which is not always the case.

Actually, i had already tried to rotate the HUD before deciding to drop that approach and use move instead. The reason was that the Luminosity slider of the embed Chimera's Color Picker was reversed when i was rotating the HUD back on screen.... and that was the only child prim doing that back then (it was even before I open the Chimera Color Picker thread). I do recall i was struggling and experimenting with all those diff kinds of coordinates, plus the diff behavior depending on the nature of the prim (root, or child, attached or not, etc). Obviously I was doing something wrong, but the botom line is that i got so confused and frustrated that i decided to drop that approach altogether and try something else (that is, moving instead of rotating).

So now that rotation came up again as a pretty good option (as the Catwa's HUD example demonstrates, at least to my eyes), I thought I should ask the forum about it, hoping for pointers that would spare me the struggle i faced when i 1st tried. I can't really test it right now, but I certainly will and get back.

[hectic1]

Just wanted to add that rotation worked just fine too, ty Rolig

For the moment I'll settle with Innula's initial suggestion of just moving the root which is simple, effective and requires the least changes in the already written code. Plus when minimized, the HUD really gets out of the way (I move it to the bottom of the screen, by only changing the z-coord... I keep the y-coord the same as the restored HUD, so if I have moved the HUD, the minimization only affects the vertical pos).

Thank you all

Edited April 8, 2017 by hectic1 Resident