Highlight Transparency messed-up?

[Marjolaine Seymour]

For ages I have used the 'Highlight Transparency' to help sorting out matters with invisible objects and attachments.
In a recent release things seems to have changed so that in certain cases a lot of objects (mesh?) now show up in red or blue when checking-in 'ctrl-alt-T'.

In my case the change makes some if my regular work almost impossible... do we know if there are any deep system variables or settings that can be changed to restore the previous functionality?

[Qie Niangao]

Surely this would depend on which viewer got the "recent release"—but also, I'm not sure what's different from how it has worked for ages: blue tint for masked alpha and red for blended alpha. Unless you're saying 24-bit textured (no alpha-channel) surfaces are also showing with a tint.

(If that's the case, hmm… I could imagine some viewer offering something like that to highlight faces with normal- or specularmap materials, maybe, but surely that would be a debug options or something.)

[Marjolaine Seymour]

It turned-up when I installed the latest version of Firestorm recently, and it is claimed to be an LL change.

With this change an avatar using mesh body/head now becomes blue and red highlighted.. instead of in the past only worn invisible attachments. I can see similar issues with mesh objects and invisible objects linked in my builds.

Question is whether all this is 'hard-coded' by LL, or if there are any system parameters which can be altered via advanced or debugging menus? Basically, I'd like to find a way to restore previous functionality, if at all possible.

Edited September 14, 2022 by Marjolaine Seymour
Clarification of changed color-highlighting

[Qie Niangao]

Oh, the avatar! Yeah, I see what you mean now, and I can even see some utility to being able to tell whether an avatar is set for blended or masked alpha. And I see it in the latest Linden viewer (6.6.4.574885) but not in Catznip, so it's apparently a change in the Linden viewer code, inherited by Firestorm (and eventually, all TPVs, presumably). Now I, too, wonder if there's a switch somewhere to revert to the old behavior.

[Marjolaine Seymour]

This is the time where I would have wished I had a contact with some FS developers... since it still works with the old viewers, it is definitely an update which went into the LL base symbolics for the viewer.

As such it should in theory be possible for some TPV developers to retrofit the old behavior and add an advanced option to switch between LL default and the retrofitted old version -  question is of course how 'messy' the correction was - a TPV dev would assess whether it will become a nightmare to carry forward? And every piece of local code means extra work in the future.

[Qie Niangao]

There is an in-world group for Firestorm support. If I dig a bit I can find it, but you may have it already. 

I'm reminded that mesh avatars (and heads) are just attachments. Playing around with stuff in Catznip, it appears that rigged alpha-textured attachments don't get highlighted, but unrigged ones do. Somehow that distinction isn't present in the (default?) behaviour of the newer code.

 

[Wulfie Reanimator]

1 hour ago, Marjolaine Seymour said:

With this change an avatar using mesh body/head now becomes blue and red highlighted.. instead of in the past only worn invisible attachments. I can see similar issues with mesh objects and invisible objects linked in my builds.

Do you mean solid red/blue, instead of that partially-transparent cloudy texture?

If the texture cache problem still going on, you should teleport to the sim Debug1 or Debug2.

[Marjolaine Seymour]

Firestorm Support basically told me "working as designed (by LL)".
I presume that is not the way to go if suggesting a new FS 'feature', but even after so many years, I have no idea where to go with such a question . It would help if I had the change-ID of the LL-change that altered the well-established functionality, because then I would quote that.

[Marjolaine Seymour]

1 minute ago, Wulfie Reanimator said:

Do you mean solid red/blue, instead of that partially-transparent cloudy texture?

If the texture cache problem still going on, you should teleport to the sim Debug1 or Debug2.

No.... it is a lot of objects which for 10+ years have not been shown in red (or blue) hue now all of a sudden do so with the recent viewer-update.

[Qie Niangao]

In Catznip, which doesn't have the change yet, an unworn mesh highlights transparent, but once that same fitted mesh is worn, it's no longer highlighted. The newer behavior is to highlight it, regardless of whether it's worn or rezzed free-standing.

I'm not a viewer developer, so this is a shot in the dark, but last December there was a commit with comment "SL-16468 Fix for crash when enabling highlight transparent (add rigged mesh support to highlight transparent)." No idea what release first got this, or if it introduced the highlighting of rigged mesh attachments or fixed a crash in an earlier change, or if it's even relevant. But this might be somewhere to start for somebody able to dive into the source.

[sandi Mexicola]

might be related: 

https://jira.firestormviewer.org/browse/FIRE-32087

https://jira.firestormviewer.org/browse/FIRE-32132

 

 

Edited September 19, 2022 by sandi Mexicola