HUD attachment not visually updating when a transparent object is moved through a transparent layer.

[Mabarial]

Hoy folks!

I encountered a rather odd bug when making my first HUD. Basically, any time a partially transparent prim passes through another partially transparent prim, the HUD has issues visually updating the change. This works the same with both SL transparency and texture transparency (masking).

Here's a video demonstrating the problem:

 

The two HUDs you see are the same object. The one on the left has no textures, the one on the right has a single transparent texture. The red cubes are transparent themselves, using SL's built-in prim transparency. They are being moved through the transparent background object using the following script:

integer gmakeVisible;
default
{
    on_rez(integer start_param)
    {
        gmakeVisible = 0;
    }
    
    touch_start(integer total_number)
    {
        if (gmakeVisible == 0) {
            llSetLinkPrimitiveParamsFast(3,[PRIM_POS_LOCAL,<-0.327080,0.150024,-0.103272>]);
            llSetLinkPrimitiveParamsFast(4,[PRIM_POS_LOCAL,<-0.327080,0.050018,-0.103272>]);
            llSetLinkPrimitiveParamsFast(5,[PRIM_POS_LOCAL,<-0.327080,-0.049988,-0.103272>]);
            llSetLinkPrimitiveParamsFast(6,[PRIM_POS_LOCAL,<-0.327080,-0.149963,-0.103272>]);
            gmakeVisible = 1;
        } else {
            llSetLinkPrimitiveParamsFast(3,[PRIM_POS_LOCAL,<-0.127080,0.150024,-0.103272>]);
            llSetLinkPrimitiveParamsFast(4,[PRIM_POS_LOCAL,<-0.127080,0.050018,-0.103272>]);
            llSetLinkPrimitiveParamsFast(5,[PRIM_POS_LOCAL,<-0.127080,-0.049988,-0.103272>]);
            llSetLinkPrimitiveParamsFast(6,[PRIM_POS_LOCAL,<-0.127080,-0.149963,-0.103272>]);
            gmakeVisible = 0;
        }
    }
}

You can see later on in the video that right clicking the prim instantly updates it, making the visually bugged red cubes appear at the correct position each time. This visual error only happens with HUD-attached prims, it doesn't occur when it's actually rezzed in-world.

 

Just something I thought was odd. Have any of you ever encountered this before? If so, what was your solution? I luckily have an easy workaround, which is just to make my cubes opaque, but I imagine there's others out there who aren't so lucky.

[Rolig Loon]

integer gmakeVisible;default{    on_rez(integer start_param)    {        gmakeVisible = 0;    }        touch_start(integer total_number)    {        float PosX = llList2Float([-0.327080,-0.127080],(gmakeVisible = !gmakeVisible) );        llSetLinkPrimitiveParamsFast(LINK_SET,[PRIM_LINK_TARGET,3,PRIM_POS_LOCAL,<PosX,0.150024,-0.103272>,PRIM_LINK_TARGET,4,PRIM_POS_LOCAL,<PosX,0.050018,-0.103272>,PRIM_LINK_TARGET,5,PRIM_POS_LOCAL,<PosX,-0.049988,-0.103272>,PRIM_LINK_TARGET,6,PRIM_POS_LOCAL,<PosX,-0.149963,-0.103272>]);    }}

See if that makes any difference.

[Mabarial]

Hey Rolig!

Thanks for the reply. No difference when using that script. I can send you a test object in-world if you'd like to play around with it.

[Rolig Loon]

Bummer.  It was a stab in the dark.  I thought maybe updating them sequentially was somehow causing the problem.

Sure.  Send it along.  I can't promise any brilliant insights, but it's an interesting puzzle to play with.

[Mabarial]

I sent it along, hope you have fun with it!

I've tried using other calls like llSetPos() and llSetLinkParams(), but the same result. I have an easy way around it by just not making my buttons transparent, but I always thought it was nice to try to solve things for other people who come along, so I'll be keeping at the puzzle, too.

[revochen Mayne]

I had this annoying bug appearing several times when working on HUDs. There are a few solutions for this problem. The easiest is to get rid of the transparent texture, especially if its the background and doesn't really need any transparency on it. Use jpg files for any texture without transparency.  Another way is to right click on the HUD to make the prim visible. Not a good solution if its for a product and involving customers.

Now the solution which might helps you: Try to either rotate or scale the prim when applying the texture on it. Maybe it needs to be done in a separate function call to make it work though. Also try to make the prim buttons flat and with a good distance to the prim below it, so they don't stuck in each other.

[revochen Mayne]

And another workaround for this bug: Put a solid prim with a blank texture on it between the conflicting transparent textures. Just show this solid prim for a very short moment after applying the button textures and hide it again then.

[Mabarial]

---

revochen Mayne wrote:

Now the solution which might helps you: Try to either rotate or scale the prim when applying the texture on it.

---

The prim being failed to update visually can happen with no textures on it, with just the prim alphas set to something above 0 but below 100%. But I went ahead and tried making a call to rotate after each movement of the prim, and found something interesting:  Setting PRIM_ROTATION causes it to visually fail to update 100% of the time. Even if I set a ridiculously long llSleep() function after the rotation is called (separately from the movement), it will fail to update every time.

But here's the kicker: You can still see it rotate. You can visually see the object rotate, but the position on the X axis does not change visually. So this bug is even weirder than I first thought.

---

revochen Mayne wrote:

And another workaround for this bug: Put a solid prim with a blank texture on it between the conflicting transparent textures. Just show this solid prim for a very short moment after applying the button textures and hide it again then.

---

 Toyed around with this, too, and it does work, but only if you put in an llSleep() function > 0.25 seconds in between making the blank solid prim visible and invisible again. That's a really long time for that prim to be visible in most use-cases.

 

Thanks for both of the suggestions!

[Mabarial]

Found an interesting workaround after reading a comment by Innula Zenovka from a thread in 2013.

 

According to Innula, there's a known bug for minor movement updates to not be updated visually in attachments. I'm guessing that the transparency somehow exacerbates this issue, so I went through some testing, and sure enough:

Transparent objects passing through one another have to be moved a certain distance for the engine to properly register an update to the attachment. A distance of 11.9m is too minor, and > 11.9m but < 12m is rather iffy. I did have a few times where distance > 12m but < 20m failed, but generally 12m and up was reliable.

That's a rather large distance to still be considered "minor", though.