🪰 Viewer Bug Reports

I've become aware of a texture rendering issue that impacts textures when on a face. It's not so much an issue that only impacts PBR textures, but it is exponentially worse and makes certain designs as mastered in Substance unusable as PBR. I'm not enough of a rendering brain to understand what is going on here, but it's my belief this is not correct and is a bug. I hope that this will get in front of the right people to be evaluated and hopefully fixed. This is being demonstrated with a 0-25% gray bi-linear gradient, however anything that uses color and gradients near this will exhibit the same obvious defects. A single example using real-world art is included for reference. Texture UUIDs Dark gradient lossy: cac83520-08b2-500f-b683-1ede13d4e052 Dark gradient lossless: bd66f42c-6b56-780e-c183-3307151f8292 Raw files, non-anotated screenshots, and sample items shown are available upon request but I don't think they will be necessary. As I was sharing this around with creator friends moments before submitting this I was made aware this may be or have been a known bug, and can be alleviated entirely on the material side by setting the alpha mode selector to blended. Masked and opaque do still exhibit the shown issues. This made me frown. There is no alpha channel on the textures shown.

First noticed this with Firestorm 7.1.12 (77610), there is a relatively quiet, murmuring wind noise looping constantly as long as the avatar is hovering but not moving. Not as loud as the wind noise when flying, so it is a different sound which is not supposed to be playing at all while stationary. This sound is also attached to the camera and not the avatar, so when zooming or moving the camera around the sound keeps playing, coming from the camera position. Upon stopping flying, the sound stops instantly, it seems to be consistent with the avatar hovering in one spot. According to others this has already been present in Second Life Viewer 7.1.11. When I first tested it with Second Life Viewer 7.1.12 I couldn't hear this noise even though master and ambient volume settings were at maximum. Since others could hear it though I checked again and now I could hear the noise in this viewer as well, even though it wasn't as loud as in Firestorm. The expected behavior of the avatar flight wind noise is to only play when moving up, down, forward, back, left or right, when simply hovering no noise should occur. Steps to verify: 1: Stand still (no flying) - no wind noise 2: Fly up - after a brief wind noise that is supposed to be there while flying up, a quiet murmuring wind noise will loop constantly 3: Fly in any or all directions for a while - normal wind noise will play while moving 4: Stop moving - the quiet murmuring noise will keep looping again while hovering 5: Stop flying - the noise will stop immediately

I have been working with a Firestorm dev on this issue, he has pretty much sorted out the repeats per meter not working at all, but... Now he has the ui working, there is a disconnect from the Blinn-phong in that with BP textures the repeats per meter uses the texture aspect ratio for repeating, as you would expect. The PBR repeats per meter is using the objects aspect ratio and changes the texture to match that and repeat. Not only is this for the majority of cases not the expected behaviour given most textures are 1:1 ratio and designed to be repeated AT that ratio, it is also a complete disconnect from the BP and PBR workflows where the same UI elements will produce different repeats.

I am not sure if this is the right place to post this so if it's not please somebody recommend a more specific form recently we had both of our regions converted over to web RTC. We did this understanding that this is the future and we might as well get used to it now and avoid the rush when the world converts. However there are a few things that I have noticed that are concerning. There are times when you're in world and ones voice can sound quite robotic almost like it's dropping packets. The temporary fix seems to be unclick your voice key scroll way out from the distance hit the escape key to return to normal view and then re toggle on your voice. I have no idea why this works but it seems to fix it temporarily. Web RTC also seems to use a very different calibration of voice levels whereas when you can hardly hear somebody their voice brackets are in bright red in in a regular SIM would be over modulated. I am not sure are these things that LL knows about or who to talk to regarding these concerns. The individual individual volume control for other specific users do not function. The Voice waves are not correct

On Mac laptops, when using the WASD keys for movement, using the A and D keys (to turn your avatar, etc) will cause a small character accent menu bubble to appear near chat menus or the cursor. This does happen in Firestorm as well, but does not happen on Mac desktops so I suspect some sort of keybinding conflict unique to an Apple laptop default. I can recall this going back a few years, on older Intel macbooks and persists on modern M4 MacBook Pros. This may be a repeat of another feedback post but thought I'd bump it with this posting.

Ever since the first Emoji and PBR viewer versions came out the default Deja Vu font changed in the UI, resulting in the spacing around numbers basically missing now. As a Firestorm user stuck with a pre-PBR version due to the multitude of rendering issues in PBR builds I hadn't paid much attention to UI elements as the entire viewer was mostly only good to cause massive headaches. I have only realized recently that most of the "headache factor" in these new viewer versions is the missing spacing between numbers. As you can see in the screenshots below I have created a test notecard and opened it with Firestorm 6.6.14, Firestorm 7.1.12 and the latest SL Viewer release 7.1.12. The FS 6.6.14 screenshot shows what the font used to look like with decent spacing between numbers. As you can see letters and special characters appear with the exact same spacing still, but numbers have basically no spacing now, so a string of numbers regardless of its length becomes an unreadable soup. The asterisk is also smaller than it used to be for some reason, however that is obviously not a significant problem. This doesn't only exist in the notecard editor, the spacing from numbers is missing throughout the entire viewer UI. Chat, textboxes, address bar, landmarks, all UI floaters, everything. I have compared the DejaVuSans.ttf file to its original version and apparently it is the same. Then I replaced the file in the new viewers' fonts folders with the original file, but upon launching each viewer again, no change occurred, the spacing between numbers was still missing. (Switching fonts in preferences in Firestorm, restarting the viewer, switching back to Deja Vu and restarting again also didn't change anything.) Apparently the source of this is either hidden in a .xml file (however after spending some time searching for it, I couldn't find anything that would control this behavior) or it is somewhere in the viewer code. I don't know if I'm alone with this but for me this renders new viewer versions unusable if I can't read numbers. Getting a headache after about 2 minutes because of the missing spacing is not part of the normal user experience even in SL so I assume this is a bug. I would appreciate it if the normal spacing around numbers could be restored. Additional info: I figured out it is apparently the right side bearing that is missing or scaled down and only for numbers. Having each number's right side bearing set to 125% of its normal scale brings back the exact same spacing it used to be. This is not a good solution to the problem however as it can result in UI element glitches if certain texts on buttons, tabs or panels overflow because of the modified spacing. It does show however that the viewer doesn't ignore the bearing but rather scales it down for some reason.

Really strange rendering behavior of particles when using an EEP tweaked for PBR ( RPA > 0 and ambient light black. ). Shadows/Light seems to be projected on particles, which does not makes sense, and if you enable the emissive bit (PSYS_PART_EMISSIVE_MASK), start and end colors are not rendered at all if those colors are tones of white/gray/black. Particle start color and end color not rendering correctly (Its definitely broken if those are tones of gray/white/black) ... seems like the viewer is rendering the colors according to the angle of camera vs sun, and not as defined and expected. Sun light should not affect how they are rendered that much . (Depending on the angle, its mixing start and end colors along with white and black) This breaks behavior over 6.6.17, which used to be uniform according to whatever was intended at the particle generator script.

The base color of a PBR material is inconsistent depending on whether it's opaque or alpha blended: in opaque mode, the base color's low end is crushed in a way that's consistent with a lossy sRGB-linear conversion, whereas in blend mode it is not. Steps to reproduce: 1) Rez 2 cubes 2) Apply this material by UUID on both cubes: 4123dd84-6f3e-52d0-4f8d-051d7c1a7c20 3) Set Scaling to U 0.125, V 1.0, offests U 0.24, V 0.0 to zoom into the gradient's dark end 4) Observe the intense banding at the dark end of the gradient's colors 5) Set one of the cubes into alpha blend mode instead of opaque 6) Observe that the banding disappears and the texture is displayed correctly wrt. the actual colors in the base color layer 7) Bonus: rez yet another cube, apply this texture as Blinn-Phong diffuse: bf0a0a57-8574-3f55-b5bc-eaae688b181e 8) Set scale H 0.125, offset H -0.2 to zoom into a similar region as the PBR material 9) Observe there is no banding, looking quite identical to the alpha blended PBR Demo image has opaque cube on left, blended cube on right.

I've been testing the 2025.03 beta on different machines, and on this particular machine equipped with a Ryzen cpu, a 3080m gpu and 32gb of ram, i observed intense frame inconsistency, that gets worse the more i wander around. It seems worse when getting inside and outside of a pbr probe. A side note: I also played with the max number of probes slider, i observed that if set to lower values, the rendering is completely messed up, looks a disco psychedelic show :) So i set this value back to 256. Note 1 : After i observed this frametime inconsistency, i hard reset the laptop internal power settings, i reset the bios, i re-installed the nvidia driver (this time i used the studio driver ..) and the problem persists. This doesn't occur on latest FS beta, and didn't occur in the previous SLV version. Note 2 : I also tested the viewer on an older windows laptop with a 1660ti gpu (Ryzen cpu, 16gb of ram), and on this one, the viewer does marvels. It's perfectly smooth and performance is impressive, as it's actually much better than the last time i tested it on the previous viewer. So i'm not sure what's going on, but i thought i would share :)

I began with a fresh Avatar floater, fresh from a login. I filtered for "Tori" and got a complete list of the outfits with "Tori" in the name of the outfit or contents with "Tori" in the item name.: https://gyazo.com/5e829bdd1789d74865d31b83f48845b6 If I clear the textbox using the X tool at the right end of the box and type in "!L", the result will be the complete list of the 100 or so outfits including those characters in the name (or contents). If I then type over the text in the now yellow textbox (not clearing first with the X tool), typing "Tori" I get at subset of the complete list. A list containing only those items in the previously filtered list. https://gyazo.com/64c893f0eb2f1c56918d852b039f3226 This is an example of a case that is easily reproduced. However there are numerous cases I cannot explain. For example when starting with a new filter after clearing the textbox and not getting the complete list of known instances. [2025-03-29: in some cases when known items exist in outfits and are not found in the filter, relogging occasionally corrects the issue. However I've got 46 outfits that contain an item, none of which are found using the filter; even after multiple relogs.] This has also been occurring for months in previous releases of the SL viewer. I see the same failure scenario in a recent release of Firestorm.