Have you seen this glitch?

[Arduenn Schwartzman]

Last week I started a thread on the Tech/SL Server forum about textures in SL switching from semi-transparent to opaque/non-transparent. I'm cross referencing this thread here in the General section to reach a larger audience with the following question:

Have you seen this glitch too?

More often, lately, or business as usual? Any thoughts/ideas on this phenomenon, outside of what already has been stated in the other thread and on the relevant JIRAs?

Cheers - A

Edited February 28, 2023 by Arduenn Schwartzman

[Aethelwine]

I have seen it on plants from time to time, I edit and correct them now without putting sufficient thought in to it to really gauge how often it happens except to say very rarely. I was going to suggest asking Qie about it because I recall their post on it, but I see that is already linked.

[Jules Catlyn]

I have had it happen as well. It seems random and doesn't effect all items that use alpha modes. I just correct it as well and go on with my day. 

[Pixie Kobichenko]

I’ve always seen that- in particular with studio-sky by Alex bader.  I know for certain their four season Old Oak tree likes to do it.  Why I. Do not know.  But I would just delete it & rezz a new copy.  

[Qie Niangao]

For me, it's rare now; I haven't seen it for six months and I'm around a lot of my own alpha-textured items much of the time. If it started happening more frequently, I'd suspect network gremlins. 

I really hate this bug, though. Whenever it appears, I wonder: How long has this texture been b0rked, and how many people saw it before I did?

I also wonder: If the sim can take random garbage it thinks a viewer emitted and interpret it as a command to swap the alpha mode on some surfaces, what other object properties might be similarly vulnerable? I mean, ultimately everything we can do in the editor is stuff the sim gets from the viewer, so theoretically any of it could be eligible to a scrambled signal, so what makes alpha mode the unique victim here? Or is it unique?

[Maitimo]

I've seen it on one product only (also a tree), which I stopped using more than two years ago. Haven't seen it since. So, it's definitely not a new or growing thing. 

I wonder if your tree was made by the same creator as mine?

[Andred Darwin]

I've seen it happen a few times, in a couple cases it was my mistake while editing the object, some faces (based on creators choice) supposed to use Alpha Blending and others Alpha Masking with mask cut off value above zero (or a mix of Alpha Masking cut off values), and accidentally, I had set all faces at once.. 

In other instances, the script that came with the object, was not setting the alpha mode (llsetprimitiveparamsfast) when changing the texture for the faces that need it... which in mixed objects, or objects created with drag copy, can cause that same issue ... ( for faces showing as solid instead of transparency,  the fix is to either set alpha mode as Alpha Blending, or Alpha Masking with a mask cut off value above 0, usually 100 ..., to just rez a new one of course is easier... )

Edited February 28, 2023 by Andred Darwin

[Stephanie Misfit]

Yes, I have seen it at different times. As already mentioned, on Studio Skye trees, and on some other plants as well. 

[CaithLynnSayes]

I've seen this, but not in SL. I saw this on my own (Dreamgrid) OpenSim region. I thought it was a bug with OpenSim but could not find anything.

Now since you guys are reporting this in SL makes me want to believe it might be a viewer issue although that should not make sense. But then again, OS and SL do not have the same serverside code. I believe those two forked long ago.

I'm purely guessing here but it is interesting that it happens on both.

[Prokofy Neva]

I have long seen this on certain trees that I then delete. And now I'm seeing more of it on lots of trees.

Just when I have to change my sims to spring. Annoying.

Could it be the difference between 1024 and 512 textures? But it just never loads for me.

[Perrie Juran]

There is a JIRA for this issue with a number of duplicates

https://jira.secondlife.com/browse/BUG-11333

[Ernst Osterham]

This happens to me a lot with studio skye stone walls with alpha textured ferns on it breaking.

[Conifer Dada]

I haven't encountered this problem with textures when in normal view, but I'm having problems when I select 'highlight transparent' on the advanced menu. All alpha textures now appear as almost opaque red, which makes the function unworkable. Up until this, highlighting transparent gave a red tint to all alphas, so you could still see what you're working with - now you can't. If you're in a place surrounded by alphas, everything is a single wall of red.

[Andred Darwin]

5 minutes ago, Conifer Dada said:

I'm having problems when I select 'highlight transparent'

There's a Jira ticket about that issue, and seems like the fix will be released with Maintenance T viewer ( commit is on Maint T branch, https://github.com/secondlife/viewer/commit/da3002bd0c25cfe922db1e40e46e48de9201501f )... a quick workaround is to install the PBR project viewer, and login at least once, but be aware, your graphics settings will reset after login along with a few debug settings if changed any... (you can save your current settings as a preset and restore after....) 

[Qie Niangao]

On 2/28/2023 at 4:52 PM, CaithLynnSayes said:

I've seen this, but not in SL. I saw this on my own (Dreamgrid) OpenSim region. I thought it was a bug with OpenSim but could not find anything.

This is interesting, and kind of confirms the overall theory of what's happening: The server is simply doing what it thinks the viewer tells it, and for some reason either viewers are all buggy and randomly emit changes to alpha mode or (more likely?) the protocol is specifically vulnerable to corruption in whatever the viewer sends to tell it to change those alpha modes.

The very ability to change alpha modes is relatively recent, as I recall coinciding with the introduction of Materials, so that protocol and viewer code must have changed at that point.

On 2/28/2023 at 6:45 PM, Prokofy Neva said:

Could it be the difference between 1024 and 512 textures? But it just never loads for me.

I never actually paid attention to the texture resolution; just checked three that I remember having the problem, and they were 512x512, 256x512, and 1024x512. Thinking about it, though, it would be strange for this bug to depend on resolution because it doesn't actually affect the texture at all, only the flag bits on the face that tell the viewer how to interpret the alpha channel of the texture. (It can only happen with 32-bit, alpha-channel textures, not simple opaque 24-bit textures.)

Just in passing, this particular bug is one where it won't display correctly for anybody because those flag bits are really changed on the object. The viewer is faithfully rendering what's on the object, but the object itself is corrupted on the region.

Edited March 3, 2023 by Qie Niangao
"bug" not "but"

[Conifer Dada]

On 3/3/2023 at 3:03 PM, Conifer Dada said:

I haven't encountered this problem with textures when in normal view, but I'm having problems when I select 'highlight transparent' on the advanced menu. All alpha textures now appear as almost opaque red, which makes the function unworkable. Up until this, highlighting transparent gave a red tint to all alphas, so you could still see what you're working with - now you can't. If you're in a place surrounded by alphas, everything is a single wall of red.

Just to clarify what we're seeing here. The top picture is normal view, the lower one is with 'highlight transparent' selected. All alpha textures are then shown as red. The reason the whole of the right hand side is red is because there's a large tree just out of view and the prims it's made from extend much further than its visible textures. Normally, highlighting transparent just tints the textures a translucent red, but now it makes them solid red.

[ChinRey]

On 2/28/2023 at 12:32 PM, Arduenn Schwartzman said:

Any thoughts/ideas on this phenomenon, outside of what already has been stated in the other thread and on the relevant JIRAs?

Nothing new but I can repeat something I said in the old thread about it: the workaround is to lock the object.

The alpha switch bug is caused by miscommunication between the server and the viewer of the owner (or somebody else with editing rights to the object). If an object is locked, nobody will have editing rights to it so the problem goes away.

Edited March 6, 2023 by ChinRey

[Arduenn Schwartzman]

12 hours ago, ChinRey said:

the workaround is to lock the object.

The alpha switch bug is caused by miscommunication between the server and the viewer of somebody who has editing rights to the object

I appreciate the suggestion for a work-around, but it basically defeats the whole purpose of granting someone your edit rights - i.e.: first, you grant someone your edit rights, and then you have to lock all your foliage to prevent those from being edited/bugged. Would, in that respect, a more basic approach be to do zero things rather than to do two counter-acting things? No longer grant others your edit rights in the first place? It saves you 1. the effort of granting people your edit rights, and 2. the effort of locking everything. (Also the workaround notwithstanding, it's highly impractical on a rental estate that involves multi-person landscape management.)

It's great, though, that edit rights have been pinpointed as a probable cause.

Somewhat related, I noticed that edit rights in some regions sometimes fail. I.e. items in some region can not be edited, despite the editor having edit rights.

Edited March 6, 2023 by Arduenn Schwartzman

[ChinRey]

3 hours ago, Arduenn Schwartzman said:

It's great, though, that edit rights have been pinpointed as a probable cause.

No, you misunderstand me. "Somebody who has editing rights to the object" includes the owner. I've corrected my post to eliminate the misunderstanding.

It's actually a good idea to lock permanently rezzed objects anyway, espexially if more than one person has editing rights to them. If somebody needs to edit the object, they can always unlock it.

Edited March 6, 2023 by ChinRey

[Conifer Dada]

In my comparison pictures showing the the glitch as it affects highlighted transparent textures, the building is locked but it still exhibits the problem. I know it's not quite the same as alpha glitches in normal view, but it's likely there's a connection.

[Arduenn Schwartzman]

3 hours ago, ChinRey said:

they can always unlock it.

I just tried. They can't.

[Love Zhaoying]

5 hours ago, ChinRey said:

It's actually a good idea to lock permanently rezzed objects anyway, espexially if more than one person has editing rights to them. If somebody needs to edit the object, they can always unlock it.

I am reminded of recent posts (primarily by Prok, but also others) of nightmare scenarios were someone with edit rights completely destroyed a build, in a collaborative building environment.

It sounds to me like, letting the Owner "lock" something would be a great fix for that potential problem.