Second Life Viewer last update made insibile parts visible

[NiranV Dean]

This bug and its various degrees of intensity have been around since Materials at least. Depending on what version of this bug it dates all the way back to Meshes. Great it's finally getting some attention after 10 years or so.

There are many to choose from, here the most common ones that can cause this:

1. Rigged alpha-blended surfaces. All of them. They are treated as solid surfaces and will "cutout" other blended and transparent surfaces behind them (long ago even clouds and water).
2. Rigged invisible objects that have at least 1% glow. They will be treated as solid and visible (both shadows and for the sake of occluding things jut like the above).
3. "Invisible" rigged default Linden body parts, e.g your shape, hair, eyebrows, shoes, etc. If you use an alpha mask and in the mask you use a masked texture instead of completely disabling the body region, it will be treated as fully solid and visible, again just like the above, it can even stick through your mesh body depending on your shape and cause all kinds of weird shenanigans (like your hair getting occluded)

Sadly there is no fix for most of these. LL has to fix whatever is borked with rigged alphas (and blended alphas in general, they are treated as fully solid in the depth map, causing depth of field to go off on them). The glow thing however is an "intentional" as far as i am aware. Black Dragon has invisible glowing items disabled.

[animats]

I've been struggling with figuring out how this is supposed to work for my own Sharpview viewer. Some notes:

• Textures with alphas are examined to see if the alphas are all very close to 0 or 1. If they are, they are treated as "Alpha Masking", rather than "Alpha Blending". This prevents blend-type sort order problems for textures that don't really need blending. The threshold for "close to" is not zero, but it's small. In early SL, before "materials", you couldn't specify blend mode, so the viewer had to make the blend or mask decision by looking at the texture's alpha channel. Viewers still do that.
• There can be a land impact penalty for specifying "Alpha Masking", because that's in the material info. As soon as you do anything that requires material info, you get the new LI computation. Just setting "Alpha Masking" does that. Then your fancy sculpts are no longer 1 LI. I see this frequently in New Babbage, which is both high-detail and has much old sculpt content.
• This creates some problems with texture level of detail. At lower levels of detail, there's some smoothing, which may introduce intermediate alpha values and break that optimization. Sharpview's texture level of detail system avoids loading more texture detail than is really needed. That's going into the LL viewers, after which they'll have this problem too. Did that go in already?
• In addition to "None", "Alpha Masking", "Alpha Blending", and "Emissive", there's "default", which is what you get when there's no material info.
• Faces with blending set to "None" (but not the no-material default value, I think) are supposed to ignore any alpha channel of the texture. But they still use the "Transparency" value, which, internally, is the alpha of the base color.
• Haven't looked at avatars yet, which have some different rules.

I'm having some problems getting some dirty windows in New Babbage to look right.

Firestorm 6.6.8. You can see a little through those windows.

Sharpview 0.4.5. Windows are opaque. In Sharpview 0.4.4, the windows were translucent, but the railing sorted wrong.

Those windows are too close to the opaque/translucent threshold, I think. Suggested best practices:

• If you don't really need translucency, don't use alpha blend.
• Don't use alpha blend on faces which wrap around something. No sorting order will work right.
• Don't use alpha translucency in the 0-20% range. Almost opaque, but not quite, is troublesome. Almost transparent with a little grey tint, like most windows, is fine.
• If you're not using an alpha channel, don't put one in the texture image.

Note the railing. It's both above and below the deck, and it is a single mesh face. I had trouble with that. It has an alpha channel. If it gets "Blend" treatment, it will mis-sort vs. the deck, because, whichever one is in front, the result will be wrong. It's alphas are close to 0 and 1, but, I think, not exactly that. Because if I set the allowed threshold to 0, it mis-sorts. Here the threshold for the no-blend optimization is set to 5 out of 256.

There are a lot of cases here. A table in the documentation would be helpful to both creators and viewer implementers. Anyway, that's the view from outside the SL code.

(Too much of what I spend time on in Sharpview is trying to be bug-compatible with cases where someone carefully exploited bugs in the classic viewers to save LI. This is not fun. Where I can buy or beg copies of troublesome objects. I do so, and I have a small collection. They're mostly old sculpts from the pre-mesh days.)

[Qie Niangao]

I wonder how much the move to glTF materials might affect this. Naively, I'd have thought alpha rendering considerations were at a different level of abstraction, but PBR opens the door to surfaces with varied transparency and varied emissivity, which seems it might affect the sort. Or maybe not, I have no idea.

[animats]

12 hours ago, Qie Niangao said:

I wonder how much the move to glTF materials might affect this. Naively, I'd have thought alpha rendering considerations were at a different level of abstraction, but PBR opens the door to surfaces with varied transparency and varied emissivity, which seems it might affect the sort. Or maybe not, I have no idea.

glTF has standards and a test set.

A glTF test, showing a texture set to "Opaque" but having an alpha channel. It got "Blend" treatment, but should not have. FAIL.

A core idea behind glTF is that everything is supposed to render standard glTF the same way. So what you see in Blender and Maya, you should also see in SL.

[Ardy Lay]

If you were to happen to ask for advice from me, I would advise you to NOT add a bunch of switch logic to support exploitive hacks that never should have been perpetrated or to support rendering of things in ways that violate glTF just because that's the way Second Life has been doing it due to lack of comprehensive design.  There isn't one damned thing in Second Life that is as expensive as the least expensive real-world product that I have been forced to stop using because either support infrastructure has been dismantled, the software that runs on it is dangerous to use, fuel is no longer legal and readily available, spare parts are no longer available, some troll of a lawyer acquired some legal rights to a method and is suing for licensing fees, etc., etc....

 

[animats]

If this is a clothing issue, see Beq's Other Blog. There have been some changes made concerning clothing layering.

[Akane Nacht]

When I logged in after the latest update, it worked for a few moments then back came the glitch 😕