🪰 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.

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.

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.

I see my dot - so I am connecting  too the server or it's a false connection ? I see no sound waves for myself - other avatars are in the RED; they can not hear me and I can't hear them. Was told to wait for a region restart-  I did nothing changed. Was sent the Wiki on sl voice trouble shooting - even though it did not apply too me, its trouble shoots the Vivox  system .     BUT humor them anyway and went through each step 1. by 1. too no avail Things I have tried on my own and with help from Tech friends Both Firestorm Viewer , current and Beta  The Current SLV viewer  tried them all . White listed the recommend files  in Windows Defender installed a different Anti virus , no change  ( Avast - and the firestorm is white listed in there) reinstalled all viewers-  from scratch , deleted everything off my pc! ( a long shot)  did not work !  i didn't think it would :) Tried other accounts on my PC  same as my main . Tried 2 other pc's in the house and worked fine.  so its not blocked in my router/firewall was told it used Port 443? then is open , if that is the port its using and was blocked why would it work on other pcs? I restarted the router and unplugged it and restarted pc ... I have been to the testing regions but it doesn't work.   the old voice system does work just fine its just the WebRTC that is the problem I was thinking it was My Pc where the problem is - but having talked to support again this am.  seems too think it may not be? I  have sent my logs to support . Which is where I am at now. submitting this to form as requested by support

When looking out over water, and void regions, there is a distinct line at one point in the view with a sometimes quite large specular highlight that should not be present. The sun or moon reflections spread out to that line. It is noted that @Geenz is aware of this, that its been present in many 7.* viewers and that it could already be noted as an issue but low priority. Just reporting here as I had a clear snapshot of the issue. Attached. Try testing looking West at various times of day and in shared environment as sun is higher in west sky at http://maps.secondlife.com/secondlife/Damiano/49/5/21

Location to reproduce: http://maps.secondlife.com/secondlife/Han%20Loso/72/190/59 Steps to reproduce: Touch 3-4 perimeter buttons on the circular dialing control in front of the gate. Observe the illuminated chevrons on the gate ring itself This bug seems to present on fullbright surfaces using the legacy bumpiness options. I've isolated the component of the object that demonstrates this bug and attempted setting it to bumpiness:none and back to bumpiness:bark as it should have, and it looks much better. Changing my selection away from the item however makes it revert to the broken state. Items should not change how they look based on if they are selected or not, and legacy content should not look this different, the right example in my isolated example screenshot is completely acceptable if it can be achieved without it resetting on de-selection. Additional wacky aspect of this comes in when scaling the item: https://youtu.be/qB7tVtKFMOQ This scaling issue does not at-all repro on FS 6.x