Fix the alpha gamma value when rendering legacy diffuse textures and materials

[vldevel]

Description

With the new PBR renderer, the faces using alpha blend with a simple diffuse texture or a Blinn-Phong material are badly rendered (way too opaque), which breaks rendering for an enormous amount of "legacy" (pre-PBR) objects.

It has been proposed (1) to introduce a new "alpha gamma" parameter for faces, that would need to be set on legacy contents in order to fix the latter, which would also force to introduce a no-mod permission exception for this parameter alone, so that people owning a legacy no-mod object could still manually edit it to fix its rendering.
This proposal is ill-conceived: how can anyone, in their right mind, hope that every owner of every "legacy" object using alpha blending in SL will bother to edit the said object (supposing they even know they can do it and how to do it) ???

The proper solution is to fix the renderer itself, and automatically apply a gamma correction factor to faces not bearing a glTF material.

This commit implements this fix (which is now part of the Cool VL Viewer and proves that it works very nicely). It implements the same kind of rendering fix (at the shader level) as (2), but instead automatically detects faces rendering with a PBR material, and applies the correction to all faces not using such a material.

In the event you want to let contents creators use linear alpha channels in objects mixing legacy BP materials and PBR materials (even though I fail to see how a creator would want to do that at all), I suggest you implement an additional flag for faces, that could be set to antagonize this auto-fix (this would let full leeway about the alpha channel scale for newly created contents while not requiring to implement some weird no-mod permission exception since this flag would be set by the creator themselves).

In the mean time, this fix solves one of the remaining major issues seen with the PBR renderer.

Related Issues

(1) https://feedback.secondlife.com/bug-reports/p/pbr-client-opacity-issue-on-textures-with-alpha-channel-windows
(2) #2668

[Geenz]

Unfortunately, the issue, due to how long it's been since we released PBR, is not as a trivial as "just bring back a 10+ year old hack".

When you have something in the wild for longer than just a few months, you need to have additional parameters to better support legacy content, and new content that was produced since.

If we had that parameter exposed I'd say your fix is maybe 90% of the way there.

Unfortunately, we have no such parameter and no good way to automatically set it. So this has a very high likelihood of breaking BP content made since PBR. We can't really accept this until someone on the server can add a parameter to support this work. We ditched the last attempt to add this due to concerns around the previous attempt's permissions bypass for a dedicated alpha gamma parameter.

I'll leave this open for the time being - I've been wanting some kind of "legacy alpha blend" param for longtime that we can automatically populate for content made prior to PBR's release that we can at least apply a sane default to (on prior to Firestorm's PBR update for example, off for anything made after, and let people toggle it on mod items). The biggest problem has been trying to make a decision on the specific metric we should use to default that parameter to on or off - as with anything like this, the concern is how much content we're gonna break if we make the wrong decision.

[vldevel]

The biggest problem has been trying to make a decision on the specific metric we should use to default that parameter to on or off - as with anything like this, the concern is how much content we're gonna break if we make the wrong decision.

Well, PBR broke 20+ years of contents. How much does that count when compared to the rare, newer contents, built post-PBR, using legacy materials or simple diffuse textures with linear alpha (Gimp, Photoshop & Co do not even produce those for diffuse textures, so rendering textures coming from them without the alpha-gamma fix is wrong) ?
Is there even any such contents on the grid (please give examples: I could not find or notice any) ?

Newer builds use PBR materials, and those are unaffected by this fix...

[Geenz]

So the fun part about all of this from a rendering theory standpoint is our alpha blending was wrong for 20+ years. The blinn-phong alpha blending hack that I added in some time ago was to mitigate breaking content at the time - and likely should have never made it into the codebase in the first place when we made the partial switch to a gamma correct pipeline.

As of right now, we already have a ton of chaos over "I like <x> better under <y>" - so I'm not gonna budge on this until we have this actually parameterized. Whether that's we take into account original date of creation in the pipe to determine whether to use the alpha gamma hack or to use proper linear blending. We need a path here to mitigate more content breakage while restoring old content that was made pre-PBR.

[vldevel]

Whether that's we take into account original date of creation

This is sadly unreliable: the creation date is set at the prim creation, but what happens if you use an old prim (e.g. a megaprim created in 2006) and then apply a new (PBR-compatible) texture with a linear alpha to it ?...

We need a path here to mitigate more content breakage while restoring old content that was made pre-PBR.

I still think LL should first and foremost repair the breakages which occurred due to the hasted PBR release (which was, sadly, barely worth an alpha-quality release): the more LL waits, the more "newly induced breakages" will happen...

[Geenz]

Parameterization first. Then we can talk about the specific fields we use to set a sane default for that.

[Geenz]

Just as an update to this:

We've been discussing it internally, and this is the parameters we're likely to go with:

• Use the alpha gamma face param that was originally planned to be introduced in Alpha gamma parameters #2668
• Drop the no-mod permission workaround that was also going to be introduced there - we've generally agreed that this was a bad idea from the start.
• Default ALL content to use gamma space alpha blending. If people need to update their content to linear space, this should be a fairly small subset at this point compared to 20 years of content that wants gamma space.

I'll provide more info once we've determined a shipping vehicle for this - it's not likely to make it into 2025.07 (the next release), but rather 2025.08 (the release after)

[vldevel]

Just as an update to this:

We've been discussing it internally, and this is the parameters we're likely to go with:

* Use the alpha gamma face param that was originally planned to be introduced in [Alpha gamma parameters #2668](https://github.com/secondlife/viewer/pull/2668)

Thus, only usable on mod-ok objects ?... Or so I understand, since:

* Drop the no-mod permission workaround that was also going to be introduced there - we've generally agreed that this was a bad idea from the start.

A very bad idea, indeed. Glad it is abandoned.

* Default ALL content to use gamma space alpha blending.  If people need to update their content to linear space, this should be a fairly small subset at this point compared to 20 years of content that wants gamma space.

That's good !

FYI, I have been tinkering with my hack these past two days: there is indeed a problem with it and with some textures on alpha faces, as well as with BP materials. The problem is that the legacy materials and diffuse alpha textures should be rendered in a SRGBA buffer, and not converted to the linear space... Trying to compensate just for the gamma is insufficient.

I made changes (that will be in the next Cool VL Viewer release), and was about to commit them to this PR:

• I lowered the default alpha-gamma factor to 1.4 (1.8 was way too much for all but white textures on alpha faces).
• In class2/deferred/alphaF.glsl, I added a boost to 'final_scale' (final_scale *= pow(alpha_gamma, 0.333333)) when alpha_gamma is != 1.0, so to try and compensate for the loss of saturation due to the higher alpha.
• I removed the alpha_gamma correction from the class3/deferred/materialF.glsl shader: it just ruins everything and is "less ruined" without it...
• I changed the algorithm to apply the alpha gamma factor only to faces pertaining to objects which do not use PBR materials at all on any of their other prims/faces. The rationale is that if an object bears a PBR material, then its creator or the owner who edited it made it so that the non-PBR faces would look good in the PBR viewers, and therefore don't need this hack...
• I added a quick toggle in the Advanced menu.

[Geenz]

Yeah- so those inconsistencies is why we’re opting for an alpha gamma parameter more generally. The original idea was to have three, and I’m inclined to keep it that way:

• Gamma space (the old gamma hack that originally shipped with BP many years ago)
• Linear
• Inverse gamma (pretty much 1/gamma)

There aren’t many great ways to handle this behavior unfortunately- as we started to standardize the pipe with PBR that resulted in a lot of the old hacks becoming fragile. So random boosting and such is expected to try and match legacy behavior- and I expect that it’ll get weirder with stuff like physically based lighting and the like. But we’ll cross that bridge when we get to it.